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AMERICAN  DEFENSE  PREPAREDNESS  ASSOCIATION 

DEDICATED  TO  PEACE  WITH  SECURITY  THROUGH  DEFENSE  PREPAREDNESS 


Founded  1919 


THE  MISSION 
OF 

THE  AMERICAN  DEFENSE  PREPAREDNESS  ASSOCIATION 


The  American  Defense  Preparedness  Association  exists  solely  for 
the  advancement  of  adequate  national  defense  of  the  United  States 
in  the  fields  of  weapons  technology,  production,  and  logistics. 

We  strive  to  improve  the  effectiveness  and  efficiency  of  the 
Government-Science-Industry  relationship  in  the  development  and 
production  of  weapons  and  weapons  systems.  Our  field  of  interest 
covers  all  ordnance,  armament,  weapons,  weapons  systems,  and 
related  equipment  for  the  Armed  Forces  of  the  United  States.  Our 
interest  also  includes  techniques,  processes,  and  materials  that 
have  wide  application  in  the  development,  production,  and 
logistics  of  weapons. 

Through  its  publications  and  meetings — national,  local,  and 
technical — the  Association  endeavors  to  educate  its  members  and 
the  public  on  problems  affecting  weapons  preparedness.  Our 
technical  divisions  provide  advice  to  Government  agencies  on 
weapons  technology. 

The  Association,  founded  in  1919,  is  a  non-profit  and  non¬ 
political  organization.  It  is  an  association  of  individuals  as 
distinguished  from  an  organization  of  commercial  companies.  The 
ten  persons  nominated  by  company  members  participate  as 
individuals. 

It  is  not  within  the  scope  of  any  American  Defense  Preparedness 
Association  meeting  or  activity  to  discuss  or  be  at  all  concerned 
with  matters  of  trade,  procurement,  price,  market  or  control  or 
with  placement  of  specific  contracts  or  allocation  of  materials. 

The  Association  cooperates  to  every  practical  extent  with  other 
recognized  technical  and  industrial  associations  in  assisting  the 
Armed  Services  of  the  United  States.  Its  mission  is  to  keep 
America's  armament  strong  in  peace  and  in  war.  Its  functions  are 
as  important  and  as  worthy  of  support  in  times  of  international 
quiet,  as  well  as  in  emergency.  It  is  a  peace  society  in  purpose 
in  operations,  and  in  fact. 


AMERICAN  DEFENSE  PREPAREDNESS  ASSOCIATION 


TECHNICAL  DOCUMENTATION  DIVISION 
STATEMENT  OF  AIMS  AND  PURPOSES 


The  Technical  Documentation  Division  is  part  of  the  Defense  Manage¬ 
ment  Group  of  the  American  Defense  Preparedness  Association.  The 
division  was  formed  to  provide  the  government  and  industry  access 
to  a  group  of  experienced  and  responsible  administrators  and 
specialists  from  various  sectors  of  industry,  qualified  to  assist 
in  the  formulation  of  government  and  industry  requirements  for 
technical  documentation.  The  members  participate  as  individuals 
rather  than  representatives  of  their  companies. 

The  division  is  concerned  with  all  aspects  of  technical  documenta¬ 
tion:  conception,  analysis,  preparation,  management,  control,  and 
dissemination.  The  division's  field  of  interest  includes  engineer¬ 
ing  drawings  and  standards,  policies  and  procedures,  technical 
publications,  specifications,  configuration  controls,  computer- 
aided  documentation  techniques,  and  methods  of  data  communication. 
Duplication  of  effort  by  other  technical  and  industry  associations 
is  avoided^ 

Sections/Committees  are  established  to  study  problems  and  submit 
resulting  reports  and  recommendations.  Section/Committee  partici¬ 
pation  by  an  individual  is  voluntary  and  evidences  his  desire  to 
comprehend  government  and  industry  needs,  to  reduce  the  complexity 
and  cost  of  technical  documentation,  and  to  enhance  standardiza¬ 
tion  with  a  sincere  interest  to  serve  with  other  members  to  achieve 
these  goals. 

Division/Section  members  interface  frequently  with  their  counter¬ 
parts  in  government  and  industry.  This  association  serves  as  a 
clearinghouse  for  professional  information  interchange  and  provides 
a  stimulation  which  contributes  toward  the  success  of  the 
participant’s  work  and  enhances  the  individual's  value  to  his 
employer. 

In  addition  to  section/committee  reports  on  subjects  completed  or 
in  process,  the  Technical  Documentation  Division  convenes  annually 
and  conducts  a  program  of  timely  subjects  to  keep  the  members 
and  the  public  informed,  alert,  and  interested  in  the  problems  and 
solutions  associated  with  technical  documentation  vital  to  our 
national  defense,  industrial  accomplishments,  and  other  related 
programs. 
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1983  ANNUAL  REPORT 


OF  THE 

AMERICAN  DEFENSE  PREPAREDNESS  ASSOCIATION 
TECHNICAL  DOCUMENTATION  DIVISION 

by 

THEODORE  L.  GOLMIS 

MANAGER,  CONFIGURATION  AND  DATA  MANAGEMENT  OPERATIONS 
HUGHES  AIRCRAFT  COMPANY 

and 

CHAIRMAN,  TECHNICAL  DOCUMENTATION  DIVISION 


Ladies  and  Gentlemen,  I  would  like  to  take  this  opportunity  to  congratulate  the 
Technical  Documentation  Division  on  its  25th  birthday. 


Twenty- five  years  ago,  under  the  banner  of  Engineering  Documentation  Section  and 
American  Ordnance  Association,  the  section  became  actively  involved  in  matters 
associated  with  Defense  and  Space  Documentation.  A  small  dedicated  group, 
interested  in  problem  solving,  initiated  a  movement  that  has  lasted  twenty-five  years 


Twenty-five  years  ago  terms  such  as  "Data  Management",  "Form  1423",  levels  of  Drawing 
Computer  Aided  Engineering,  and  Tailoring  were  not  part  of  the  vocabulary.  The  pro¬ 
blems  of  that  era  were  associated  with  lack  of  communication  between  customer  and 
contractor,  compounded  by  the  lack  of  attention  to  the  problem  by  both  Military  and 
Industry. 


Twenty-five  years  ago,  men  with  insight  set  as  their  objective  for  this  section  the 
establ ishment  of  a  two-way  channel  of  communication  between  Military  and  Industry. 
They  hoped  to  provide  a  sounding  board  by  which  the  Military  could  obtain  the 
benefit  of  a  cross-section  of  industry  experience  and  could  circulate  information 
quickly  regarding  new  requirements  and  problems.  Industry  on  the  other  hand  hoped 
to  contribute  to  improvement  in  military  practices. 


What  was  our  first  annual  meeting  like?  At  that  first  meeting  25  years  ago: 

A  team  of  experts  (Chet  Nazian,  Jim  Mars,  Russ  Eaton,  Dan  Bennett,  and  John 
Dunn)  were  discussing  military  plans  for  implementation  of  MIL-D-70237. 

Stu  Miller  was  clarifying  the  grey  areas  of  true  position  dimensioning. 

Thurber  Moffett  reported  on  a  new  EAM  Documentation  records  system  developed 
at  General  Dynamics. 

Bob  Franciose  was  predicting  problems  with  Numerical  Control  Documentation. 
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The  discussion  on  whether  BuShips  and  BuOrd  would  require  all  Class  I 
customer-formatted  drawings  was  held. 

There  was  open  debate  on  what  size  microfilm  should  be  recommended  to  the 
military  as  a  standard. 

That  was  the  start  and  not  once  have  our  associates.  Government  and  Industry  with 
their  diverse  interests,  widely  different  points  of  view,  and  different  person¬ 
alities,  ever  faltered  from  their  objective.  This  week's  meeting,  like  last 
year's  meeting,  and  all  the  years  before,  is  testimony  to  the  unselfish  dedication 
for  a  common  objective  of  problem  solving  and  improved  communications. 

I  could  continue  locking  back,  highlighting  the  past  and  reminiscing,  but  I  have 
no  intention  of  doing  so— our  past  speaks  for  itself.  What  I  do  want  to  address 
is  our  aims  and  purposes  and  direct  our  attention  to  the  future. 

The  Technical  Documentation  Division  is  part  of  the  Technology  and  Management 
Advisory  Group  of  ADPA.  As  previously  mentioned,  the  Division  was  formed  to  pro¬ 
vide  the  Government  and  Industry  access  to  a  group  of  experienced  and  responsible 
specialists  from  various  sectors  of  industry,  qualified  to  assist  in  the  formula¬ 
tion  of  Government  and  Industry  requirements  for  Technical  Documentation.  The 
members  participate  as  individuals  rather  than  representatives  of  their  companies. 

The  Division  is  concerned  with  all  aspects  of  Technical  Documentation:  conception, 
analysis,  preparation,  management,  control,  and  dissemination. 

The  Division's  field  of  interest  includes  Engineering  Drawings,  and  Standards, 
Policies  and  Procedures,  Technical  Publications,  Specifications,  Configuration 
Controls,  Computer  Aided  Engineering  Techniques,  and  Methods  of  Data  Communica¬ 
tion.  Duplication  of  effort  by  other  Technical  and  Industry  Associations  is 
avoided.  Sections/Committees  are  established  to  study  problems  and  submit  the 
resulting  reports  and  recommendations.  Participation  is  voluntary  and  evidences 
an  individual's  desire  to  comprehend  Government  and  Industry  needs,  to  reduce  the 
complexity  and  cost  of  Technical  Documentation,  and  to  enhance  standardization  . 
with  a  sincere  interest  to  serve  with  others  to  achieve  these  goals. 

Our  aims  and  purposes  were  well  satisfied  this  year.  We  have  had  four  meetings, 
starting  in  January  1982  in  Arlington,  Virginia,  hosted  by  Advanced  Technology, 
Incorporated.  At  this  meeting,  Dr.  Stephen  Bryen,  Deputy  Assistant  Secretary  of 
Defense,  International  Trade  and  Security  Policy,  provided  us  an  informative  pre¬ 
sentation  on  indiscriminate  publication  of  defense  information. 

It  was  also  at  this  meeting  that  staff  members  of  ASTM  provided  a  presentation  on 
the  development  of  ASTM  documents,  as  well  as  the  aims  and  purposes  of  ASTM. 

Sam  Miller  of  Defense  Materials  Specifications  and  Standards  Office,  cited  the  33 
initiatives  for  improving  the  acquisition  process. 

I  am  just  highlighting  a  few  things  that  have  taken  place  because  some  of  the  key 
people  are  here  and  will  provide  the  current  status  of  these  projects. 
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Our  annual  meeting  was  held  25,  26,  and  27  May  at  the  Honalai  Hotel  in  San  Diego, 
California.  September  put  the  Executive  Board  at  the  Navy  Ships  Parts  Control 
Center,  Mechanicsburg,  Pennsylvania.  Ms.  Anne  Polivka,  Chairman  of  the  ADPA 
Central  Pennsylvania  Management  Chapter  and  Capt.  Thomas  Burke,  Commanding 
Officer,  Naval  Sea  Systems  Command  Logistics  Support  Engineering  Activity,  hosted 
the  meeting.  We  were  welcomed  by  Rear  Admiral  Edward  H.  Kocher,  Commanding  Officer, 
SPCC,  who  encouraged  a  free  exchange  of  information. 

Our  most  recent  meeting  was  held  at  Wright- Patterson  Air  Force  Base,  Dayton,  Qhic. 

In  addition  to  our  normal  Section  Reports,  Ray  Suc'-ioto,  Air  Force  Systems  Command 
briefed  us  on  the  methodologies  used  in  acquiring  the  F- 16  data.  Col.  Zaleski 
provided  an  overview  of  General  Marsh's  and  General  Chubb's  new  plan  to  reduce 
data  costs  within  the  Air  Force.  Roger  Faust  reported  the  status  of  the  revision 
of  MIL-STD-143.  And  Don  K.  Swanson  presented  "Cost-Benefit  Reporting  for  DOD  Parts 
Control  Programs. 

It  has  been  this  exchange  of  information  between  Government  and  Industry  that  bene¬ 
fits  both  of  us  and  strengthens  the  Technical  Documentation  Division. 

I  am,  however,  concerned  over  the  near  future.  I  fear  that  Industry's  renewed 
emphasis  on  productivity  will  accelerate  automation  to  a  degree  that  our  customers. 
The  Services,  may  not  accommodate  our  needs,  our  methods,  and  our  informational 
products. 

If  you  look  at  the  program  for  this  meeting,  you  will  see  such  terms  as  "Optical  Disc 
Storage  for  Technical  Record  Control",  "Managing  Computerized  Documentation",  "Total 
Technical  Documentation  Automation".  These  along  with  "CAD/ CAM  Application  in 
Microelectronics",  CAD/CAM  and  Parts  Listing",  "Digital  Drawing  Management  System", 
"Database  Management",  "Interactive  Graphics  and  Lazer  Disk  Storage"  verify  that 
what  we  have  said  is  comi ng  is  now  a  full  reality. 

My  concern— the  Governments  Informational  Collecting  Systems,  Specifications,  and 
Standards  are  lagging.  Personnel  are  not  prepared  to  substitute  or  tailor  these 
requirements  to  what  is  available  at  minimum  cost.  If  we  do  not  take  immediate 
action  to  modernize  our  requirements ,  we  will  continue  to  run  high  cost  dual  sys¬ 
tems  for  many  years  to  come. 

A  simple  ROM  (Read  Only  Memory)  is  a  good  example.  When  we  were  using  2K,  4K  and 
8K  ROMS,  Truth  Tables  may  have  been  of  some  value  to  our  customers.  Now  we  have 
48K,  64K,  and  Larger  ROMS— Truth  Tables  are  worthless. 

Industry  must  provide  and  Government  must  accept  new  media  of  data  transfer  to 
permit  low  cost  reprocurement. 

It  will  be  objective  of  the  Technical  Documentation  Division  to  assist  in  this 
transition  in  each  of  our  chartered  areas:  Drawings,  Configuration  Management, 
Software,  Technical  Manuals,  etc. 

The  tide  has  turned  and  we  must  lead  the  way  to  new  and  low-cost  management  systems. 


Thank  you. 
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FUTURE  TRENDS  IN  GOVERNMENT 
DOCUMENTATION 


Mr.  BERNARD  G.  LAZORCHAK 
Professional  Staff  Member 
Joint  Committee  on  Printing 
Congress  of  the  United  States 


Mr.  Lazorchak  spoke  on  future  trends  of  the  Federal  Printing 
Program  which  the  Joint  Committee  on  Printing  (JCP)  administers. 

The  overall  goal  of  the  JCP  is  to  identify  and  eliminate  delays, 
duplication,  and  waste  in  government  printing.  ("Printing"  is  used 
in  a  very  broad  sense;  covering  a  totally  integrated  system  including 
development,  editing,  preparation  of  final  copy,  printing,  and  distr- 
bution. ) 

Specific  areas  of  JCP  responsibility  include: 

•  Automation  and  standardization  of  congressional  publications. 

•  Interagency  electronic  and  microforms. 

•  Technical  liason  to  DoD  in  specifications  and  standards, 
technical  information  manuals,  and  all  aspects  of  printing. 

•  Approval  of  all  equipment  requests  relative  to  printing, 
binding,  etc. 

•  Automation  and  application  of  new  technologies  including 
generic  coding  techniques,  and  merging  of  text  and  graphics. 

Mr.  Lazorchak  described  the  need  for  uniform  application  of  advancing 
technology  in  both  technical  documentation  and  configuration  manage¬ 
ment  to  support  a  fully  integrated  system. 
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WELCOME 


LIEUTENANT  GENERAL  JULIUS  W.  BECTON,  JR. 
Deputy  Commanding  General,  Training 
Inspector  of  Training 
U.S.  Army  Training  and  Doctrine  Command 
Fort  Monroe,  Virginia 


Note:  The  following  is  an  edited  transcription  of 

General  Becton's  remarks. 


On  behalf  of  General  Richardson,  I'd  like  to  welcome  the  ADPA 
Technical  Documentation  Division  to  Fort  Monroe. 

I'd  also  like  to  take  this  opportunity  to  focus  your  attention  on  the 
challenge  of  training. 

I  am  convinced  that  today's  technology  and  its  applications  provide  a 
way  for  us  to  do  more  with  less.  The  most  challenging  goal  of  the  next 
decade  is  to  increase  troop  readiness  while  at  the  same  time  reducing 
training  resources.  For  example,  use: 

•  Substitute,  less  powerful  ammunition  in  training  excerises. 

•  Electronic  simulators  for  low  cost  combate  training  of  man/ 
vehicle  operation. 

•  Computer  based  tactical  simulation  systems  followed  by  field 
exercises  to  minimize  the  enormous  cost  of  real  field  exercises. 

Given  that  we  all  agree  upon  the  use  of  such  things,  there  may  still  be 
a  more  fundamental  issue  facing  the  Army: 

How  do  we  train  today's  soldier  to  operate  today's  weapons  to 
maximum  effectiveness? 

Modern  technology  is  surely  changing  our  world — in  the  office,  in  the 
factory,  and  on  the  battlefield.  The  myriad  of  new  weapon  systems,  both 
fielded  and  in  the  future,  appear  logical  on  the  engineering  drawing 
table,  but  they  must  ultimately  be  operated  by  soldiers  who  have  been 
properly  trained. 

"Hi-tech"  is  the  buzz  word,  not  only  in  the  services,  but  in  industry 
and  in  education. 

Assuming  you  agree  with  me,  that  we  are  in  an  era  of  hi-tech  weapons, 
what  is  the  problem  of  hi-tech  training? 
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The  Defense  Science  Board  has  just  released  its  findings  from  the  study 
they  conducted  last  summer  on  Training  and  Training  Technology.  Their 
conclusions  may  serve  as  a  spring  board  for  any  follow-on  discussions 
you  may  have  at  this  meeting.  They  concluded: 

"We  must  take  advantage  of  current  technology  and  press  for 
the  release  of  emerging  technologies  to  develop  ways  to  make 
training  more  efficient  and  effective." 

In  the  remainder  of  the  report,  the  Board  stressed  the  need  for  strong 
organizational  cohesion  in  consolidating  technological  gains  and  train¬ 
ing  technology  in  applying  hi-tech  innovations  to  training. 

While  it  might  appear  that  this  is  only  motherhood,  apple  pie,  and  Sunday 
baseball,  I'd  like  to  offer  some  comments  to  those  on  the  hi-tech  road. 

Before  we  go  too  far,  let's  ask  ourselves  some  basic  questions  about 
training  and  our  intensifying  technology. 

•  First,  do  we  really  know  how  deficient  we  are? 

•  What  training  is  deficient? 

•  Which  areas  are  most  in  need  of  updating  or  improvement? 

•  Which  areas  are  in  less  need  of  hi-tech  assistance? 

We  must  concentrate  hi-tech  resources  in  areas  where  hi-tech  will  most 
likely  pay  off.  We  must  remember,  hi-tech  provides  only  the  tools 
for  training;  not  the  training  itself.  A  computer  simulator,  if  not 
properly  programmed  can  deliver  bad  training  just  as  easily  as  the  good 
training  that  was  expected. 

Another  challenge  which  is  equally  important: 

Training  is  a  continuing  process — like  cleaning  house.  When  you  think 
you've  finished,  its  time  to  start  over.  It's  a  matter  of  hurry  up  to 
wait.  A  lot  of  soldiers  spend  a  lot  of  time  waiting  to  do  their  thing. 
That  time  could  be  filled  with  technology  so  that  they  could  better  do 
their  thing,  when  it  comes  time. 

The  trainer,  and  the  trainer's  trainer,  and  so  on  up  the  chain  of  command 
are  increasingly  busy  because  they  have  so  much  more  to  do.  In  this  field 
(that  is  high  technology),  there  is  much  talk  about  making  the  systems 
friendly  from  the  users'  viewpoint.  I  suggest  that  friendly  to  a  user 
is  one  thing,  but  friendly  to  a  trainer  may  be  quite  another.  There 
must  be  a  better  way  to  document  the  kinds  of  things  that  we  need. 

Well,  I  was  given  ten  minutes,  so  I  better  stop  here.  I  was  only  asked 
to  welcome  you,  not  to  sermonize  you.  But  I  couldn't  pass  up  the  op¬ 
portunity  to  suggest  to  you  some  ways  in  which  you  might  help  us.  The 
Army  is  in  good  shape,  but  we  can  do  better.  We  must  do  better. 

Again,  welcome  to  TRADOC  and  Fort  Monroe.  Good  luck  with  your  Twenty- 
Fifth  Annual  Meeting .  God  bless. 
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TRADOC  SPECIAL  ARMY  BRIEFING 


MAJOR  GENERAL  DONALD  R.  MORELLI 
Deputy  Chief  of  Staff  for  Doctrine 
U.S.  Army  Training  and  Doctrine  Command 
Fort  Monroe,  Virginia 


General  Morelli  presented  a  very  informative  slide  briefing,  sum¬ 
marizing  the  techniques  and  philosophy  used  in  developing  doctrine 
for  future  weapons  systems.  He  described:  (1)  U.S.  Battlefield 
Development  Plan;  an  umbrella  concept  supported  by  a  series  of 
functional  concepts  and  (2)  Air-Land  Battle  2000  covering  the 
time  period  of  1995-2015. 


The  fundamental  approach  considers: 

•  How  do  we  want  to  fight  in  the  future? 

•  How  did  we  solve  this  problem  in  the  past? 

•  What  is  the  worldwide  threat  potential? 

•  What  are  the  technological  trends  for  the  future? 


He  pointed  out  that  the  emphasis  is  on  identifying  how  we  want  to 
fight,  based  on  the  threat;  then  determining  how  emerging  technol¬ 
ogies  can  be  applied  to  eliminate  deficiencies  which  have  been 
identified  and  prioritized.  This  is  in  contrast  to  the  past,'  when 
available  equipment  tended  to  dictate  the  ways  in  which  we  planned 
to  fight. 


General  Morelli  identified,  as  a  key  problem,  the  disclosure  of 
our  nation's  technology.  Russia  readily  admits  that  they  cannot 
modernize  their  armies  without  the  use  of  Western  technology. 
Other  areas  of  concern  are  the  Soviet  Power  Projection  and  poten¬ 
tial  deficiencies  in  strategic  materials. 


He  also  highlighted  the  need  systems  designers  to  understand  how 
people  learn.  "Young  people  today  learn  from  interacting  with  the 
game;  (not  by  reading  instructions)."  He  predicted  that  in  the 
future,  the  mandate  of  leadership  will  be  pushed  to  lower  levels 
than  ever  before.  We  can't  forget  the  soldier. 


PROCUREMENT  PRACTICES  STUDY 
by 


Matthew  E.  Brislawn 
Boeing  Aerospace  Company 


SUMMARY 


A  study  was  conducted  on  the  E3  (AWACS)  program  to  determine  if  it  is 
feasible,  without  increasing  program  risk,  to  reduce  program  cost  by 
simplifying  Government  procurement  practices.  A  review  was  made  of  contract 
terms,  specifications,  and  data  items;  comparisons  were  made  with  comparable 
cormierc ial  activities.  The  conclusion  was  that  substantial  savings  could  be 
achieved  if  the  Government  would  change,  modify  or  waive  certain  standara 
procurement  practices  or  regulations. 
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INTRODUCTION 

In  mid  1981,  as  a  result  of  the  decline  in  the  commercial  airplane  market, 
Boeing  conducted  a  series  of  reviews  called  organizational  depth  studies. 
These  reviews  were  conducted  by  a  small  group  of  corporate  executives.  There 
were  over  30  reviews  conducted  throughout  the  company  on  both  commercial  and 
military  programs.  The  purpose  of  these  reviews  was  to  assure  that  overhead 
and  management  costs  would  be  reduced  consistent  with  declining  direct  manu¬ 
facturing  and  engineering  effort.  At  various  times  in  our  history  when  we 
have  had  cut-backs,  direct  costs  would  decline  at  a  much  faster  rate  than 
overhead  and  management  costs;  the  depth  studies  were  intended  to  assure 
that,  this  time,  indirect  cost  would  be  reduced  with  direct. 

On  several  occasions,  when  the  reviewers  asked  that  a  particular  activity  be 
discontinued,  they  were  told  that  it  was  a  Government  contract  requirement 
and  therefore  could  not  be  stopped.  After  hearing  this  same  explanation  a 
number  of  times,  they  decided  that  the  Government  was  no  more  interested  in 
perpetuating  uneconomic  management  practices  than  Boeing  was.  Based  on 
requests  received  from  Air  Force  Systems  Command,  they  directed  that  a  study 
be  conducted  to  advise  the  Air  Force  of  current  procurement  practices  which 
were  causing  the  cost  of  the  final  product  to  be  unnecessarily  increased. 

The  procurement  practices  study  was  initiated  in  September  of  1981  and  was 
completed  in  February  of  1982.  The  results  of  this  study  were  presented  in 
March  to  the  Air  Force  Electronics  Systems  Division  (ESD).  A  commitment  was 
made  at  that  time  that,  if  the  Air  Force  would  implement  the  procurement 
practices  changes  recomende d,  Boeing  would  not  only  reduce  the  prices  of 
future  contract  work  but  would  pass  on  savings  by  reducing  the  price  of 
existing  contracts.  ESD  supported  the  majority  of  our  recommendations  and 
requested  that  we  proceed  to  prepare  firm  contract  proposals. 

The  objective  of  the  procurement  practices  study  was  quite  specific;  we  were 
to  reduce  product  cost,  that  is  the  cost  of  developing  and  manufacturing  the 
hardware,  by  recommending  changes  to  or  simplifications  of  government  pro¬ 
curement  practices  in  those  areas  where  this  could  be  done  without  adverse 
impact  on  product  performance,  quality,  or  operating  costs.  In  other  words, 
eliminate  those  practices  which,  from  an  economic  point  of  view,  did  not, 

improve  the  end  item  product.  The  study  was  to  be  conducted  using  a  single 

program  as  a  test  case.  The  Airborne  Warning  and  Controls  System  (AWACS),  or 
E3,  program  was  selected  for  the  study.  AWACS  was  selected  for  several 
reasons,  perhaps  the  most  important  of  which  was  that  it  was  the  largest  cur¬ 
rent  military  program  in  The  Boeing  Company.  AWACS  is  a  long,  stable 
program;  development  began  in  1970,  production  started  in  1975,  and  we  expect 
the  program  to  be  in  production  at  least  through  the  end  of  this  decade. 

The  selection  of  the  AWACS  program  dictated  one  of  the  early  findings.  As  in 
many  studies  of  similar  nature,  the  first  thing  that  the  study  team  looked  at 

was  engineering  and  manufacturing  specifications,  to  see  if  there  wasn't  a 

more  simple  cost  effective  way  to  build  the  product.  On  a  product  that  began 
design  12  years  earlier  and  had  been  in  production  for  seven  years,  it 
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quickly  became  apparent  that  the  cost  of  implementing  significant  design  or 
manufacturing  changes  would  more  than  offset  any  savings.  Therefore,  one  of 
the  first  conclusions  of  the  study  team  was  that  there  would  be  little 
economic  justification  for  changing  the  engineering  or  manufacturing  specifi¬ 
cations  in  mid  production. 

An  initial  task  of  the  study  team  was  to  identify  procurment  practices 
imposed  on  us  by  contract.  Contract  requirements  come  from  a  variety  of 
sources;  the  team  identified  and  screened  217  separate  terms  and  conditions, 
318  military  specifications  and  standards  that  are  referenced  in  the  con¬ 
tracts,  566  contract  specifications,  and  over  375  different  contract  data 
items.  In  addition,  a  large  amount  of  effort  was  spent  comparing  military 
program  practices  with  conmercial  programs,  where  we're  basically  spending 
our  own  money.  Many  of  our  recommendations  resulted  from  differences  between 
the  way  we  do  things  for  the  military  and  the  way  we  do  them  on  commercial 
programs. 

AWACS  has  had  a  good  history  of  cost  consciousness.  When  the  program  was 
started,  many  specifications  were  specifically  tailored  in  recognition  of  the 
fact  that  a  commercial  707-320  airplane  was  being  used  to  help  reduce  program 
costs.  When  the  NATO  and  US  standard  program  was  implemented  in  1980,  they 

were  effectively  procured  as  a  single  package  of  27  systems  (18  NATO  and  9 

US),  in  effect  providing  the  USAF  whith  the  advantage  of  a  multi-year  buy 
with  NATO.  We  have  had  numerous  cost  reduction  suggestions  implemented  on 
the  program- ( some  $59M  in  1981  alone),  but  we  still  felt  that  there  was  room 
for  further  improvement.  We  are  continuing  our  internal  cost  reduction  pro¬ 
grams  and,  with  the  recommendations  in  this  study,  sought  Air  Force  and  000 
support  to  implement  more  cost  reductions. 

The  conclusions  of  the  study  were  reflected  in  11  separate  recommendations. 
The  best  way  to  sunmarize  these  recommendations  is  that  the  Air  Force  should 
be  much  more  selective  and  discriminating  in  the  application  of  procurement 
regulations  and- practices  to  an  individual  program.  The  program  started  in 

the  development  phase  with  a  number  of  requirements.  As  the  program  moved 

through  time  with  changing  requirements,  additional  procurement  regulations 
and  practices  were  imposed;  virtually  none  were  dropped.  There  was  no  real 
attempt  through  the  12  year  life  of  the  AWACS  program,  by  either  Boeing  or 
the  Air  Force,  to  recognize  that  risks  had  changed,  the  program  had  changed, 
and  practices  that  may  have  been  fully  justified  ten  years  ago  in  the  middle 
of  full  scale  development  or  at  the  start  of  production  are  simply  not  cost 
effective  today. 

RECOMMENDATIONS 

1.  Tailor  Management  Reporting 

The  first  of  the  11  recormendations  was  to  tailor  management 
reporting.  The  reporting  requirements  on  contract  are  not  asso¬ 
ciated  with  risk.  At  the  time  of  the  study  there  were  no  contracts 
on  the  AWACS  Program  in  an  overrun  situation  and  yet  we  still  sub- 
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mitted  routine  monthly  cost  reports  on  over  1,000  cost  accounts  for 
each  of  the  contracts.  We  still  provide  a  variance  analysis  on 
variances  that  occurred  two  or  three  years  ago  on  contracts  that 
have  another  year  or  more  to  complete.  There  is  a  great  deal  of 
repetitive  reporting  at  a  level  of  detail  not  consistent  with  the 
risks  of  the  program.  We  are  recoimending  that  there  be  an  expanded 
use  of  exception  reporting  rather  than  detail  reporting;  that  the 
frequency  of  cost  and  schedule  reporting  be  extended,  for  instance 
that  most  reports  be  provided  quarterly  instead  of  monthly;  and  that 
the  level  of  reporting  be  raised,  that  is,  report  them  at  WBS  level 
2  instead  of  level  3  or  4,  as  currently  reported. 

Simplify  Follow-on  Procurements 

On  a  multi-year  production  program  such  as  AWACS,  we  have  follow-on 
production  proposals  nearly  every  year.  On  the  integrated  US  NATO 
Program,  there  were  over  40,000  pages  of  proposal  documentation  plus 
15,000  pages  of  specifications.  On  the  Saudi  Program,  which  was 
proposed  in  mid-1982,  we  again  exceeded  40,000  pages  of  proposal 
documentation.  It  is  our  belief  that  a  large  amount  of  this  pro¬ 
posal  documentation  is  unnecessary,  that  a  large  number  of  program 
plan  type  documents  are  updated  soley  for  the  purpose  of  the  pro¬ 
posal  and  that  the  need  to  do  that  has  long  since  past.  Therefore, 
we  recommend  that  a  concerted  effort  be  made  to  reduce  significantly 
the  size  and  complexity  of  follow-on  proposals,  and  a  greater  use  be 
made  of  the  exisiting  established  plans  with  minimum  updates 
required  only  as  required  by  major  program  changes. 

Reduce  Requirements  for  Subcontract  Cost  and  Pricing  Data 

In  many  cases  we  are  obligated  to  require  subcontractors  to  submit 
detail  cost  data,  and  we  must'  perform  extensive  cost  analyses  on 
follow-on  procurements  when  we  have  extensive  historical  or  para¬ 
metric  price  data  that  is  more  than  adequate  to  support  the  proposed 
subcontract  price.  For  instance,  in  the  case  of  the  Saudi  Tanker 
Program,  the  landing  gear  on  the  tanker  aircraft  is  virtually  iden¬ 
tical  to  landing  gears  that  we  have  been  buying  for  707  aircraft  for 
over  a  quarter  of  a  century.  On  the  other  hand,  the  aft  fuselage 
section  that  contains  the  fueling  system  is  a  new  design.  But  by 
regulation,  since  both  subcontracts  exceed  the  threshold  for  cost 
analysis,  we  are  required  to  solicit  from  the  suppliers  a  detailed 
cost  proposal  and  go  through  an  internal  analysis  of  that  cost.  In 
our  opinion,  it  would  make  much  more  sense  to  require  the  detail 
cost  proposal  and  analysis  on  the  new  fuselage  section,  and  to  rely 
on  a  historical  data  and  parametric  comparisons  for  the  landing 
gear.  The  effort  should  be  put  selectively  in  the  risk  areas,  not 
in  the  areas  where  there  is  very  little  pay  off;  the  effort  should 
be  applied  where  the  risk  and  leverage  are,  not  just  applied  to 
every  subcontract  that  happens  to  exceed  some  arbitrary  threshold. 
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Raise  Threshold  for  Mandatory  Contract  Provisions 


Many  of  the  contract  socio-economic  flow  down  requirements  have 
thresholds  as  low  as  $2,500;  many  have  been  unchanged  for  20  years. 
Inflation  alone  has  effectively  lowered  these  thresholds  to  include 
a  large  number  of  subcontractors  never  intended  to  be  included  in 
these  various  government  programs.  Many  companies,  including  some 
as  large  as  International  Harvester  and  Sears,  have  said  they  will 
no  longer  compete  for  government  contracts  because  the  cost  of 
paperwork  and  admi ni strative  procedures  far  exceeds  any  earning 
capability.  In  the  case  of  the  Boeing  Aerospace  Company,  we  have  to 
comply  with  reporting  requirements  in  a  number  of  areas  on  over  200 
separate  contracts.  The  study  team  has  recommended  that  the  thres¬ 
holds  should  be  raised  to  a  more  realistic  level;  that  small 
business  be  excluded  in  total  from  flow  down  of  many  of  the  flow 
down  provisions;  that  flow-down  not  be  required  for  firms  whose 
government  business  is  less  than  5 %  of  their  total;  and  that  all 
reporting  should  be  handled  on  a  company  wide  or  program  basis 
rather  than  contract  by  contract.  At  one  time  on  the  AWACS  Program, 
we  had  to  submit  small  business  plans  on  an  ECP  by  ECP  basis.  We 
have  gotten  that  changed  so  that  now  we  are  doing  it  on  a  contract 
basis.  In  fact,  the  only  small  business  plan  that  makes  much  sense 
for  a  program  the  size  of  AWACS  is  a  program  wide  plan. 

Simplify  Contract  Specifications 

On  the  AWACS  Program,  we  are  currently  maintaining  566  separate 
specifications  under  Class  1  control  containing  over  85,000  pages. 
The  Saudi  Program  will  add  an  additional  100  plus  specifications  to 
this  count.  It  is  our  belief  that  this  could  be  reduced  to  approxi¬ 
mately  87  specifications,  containing  less  than  30,000  pages  in  a 
very  cost  effective  fashion.  Many  of  the  specifications  that  are 
maintained  are  contract  end  item  (CEI)  specs  which,  in  our  opinion, 
should  not  be  maintained  after  completion  of  functional  configura¬ 
tion  audit  ( FCA) .  After  FCA,  only  the  top  level  system  specifica¬ 
tions  should  be  maintained.  On  a  conmercial  airplane  program  during 
the  development  phase  we  do  have  the  equivalent  of  the  CEI  spec; 
however,  once  the  design  has  been  qualified,  we  no  longer  maintain 
the  specification.  Configuration  control  is  maintained  by  part 
number  on  what  we  refer  to  an  an  envelope  drawing.  CEI  specs  are 
kept  for  historical  purposes  and  if  there  is  ever  a  requirement  to 
make  a  major  change  to  a  subsystem,  the  specification  could  be  up¬ 
dated,  but  it  is  not  maintained  current  once  the  detail  design  has 
been  approved. 

Simplify  Change  Procedures 

We  process  over  150  changes  a  year  on  the  AWACS  Program;  it  takes  in 
excess  of  one  year  to  process  the  average  change.  About  1/3  of  the 
administrative  personnel  on  the  program  are  in  the  business  of  pro- 
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cessing  changes.  We  believe  that  this  could  be  significantly 
reduced  by  combining  individual  changes  into  block  changes. 
Further,  we  are  recommending  that  many  of  the  reviews  conducted 
sequentially  by  the  Air  Force  be  conducted  in  parallel  so  that  the 
time  spent  after  a  change  is  proposed  until  it  is  negotiated  can  be 
significantly  reduced.  A  very  large  number  of  changes  must  be 
reproposed,  either  because  of  the  passage  of  time  and  the  new  facts 
that  are  discovered,  or  the  fact  that  the  work  statement  changes. 

Reduce  Contract  Data 


The  major  contracts  on  the  AWACS  Program  contain  approximately  100 
data  items  each.  We  have  over  twice  this  number  on  the  Saudi  con¬ 
tract  because  of  the  fact  that  we  are  providing  both  tanker/cargo 
aircraft  and  E-3  aircraft  on  the  same  contract.  We  have  identified 
167  different  offices  in  the  Air  Force  that  receive  AWACS  data. 
Many  data  reduction  exercises  have  rsulted  in  reducing  the  apparent 
number  of  data  items,  but  in  almost  every  case  what  these  exercises 
have  actually  done  is  prevented  the  growth  of  additional  data  items, 
not  reduced  the  number.  We  recommend  significant  reductions  in  the 
amount  of  data  required,  up  to  50%  on  most  contracts. 

Streamline  Spares  Ordering 

Under  current  practice,  initial  spares  and  production  are  bought  by 
two  different  agencies  of  the  Air  Force  at  two  different  points  in 
time.  Our  own  experience,  indicates  that,  if  we  can  buy  spares  con¬ 
currently  with  the  order  of  production  hardware,  we  can  realize 
savings  on  the  order  of  20%  to  50%.  We  have  many  examples  that 
support  these  kinds  of  savings.  We  believe  these  savings  could  be 
achieved  by  the  Air  Force  if  a  prime  contractor  could  be  authorized 
concurrently  to  order  production  hardware  and  initial  spares.  In 
addition,  the  paperworked  process  to  put  spares  order  on  contract 
takes  upwards  of  250  days.  In  many  cases,  it  takes  longer  to  pro¬ 
cess  the  procurement  paper  than  it  does  to  build  hardware;  it  is  not 
unusual  that  hardware  is  actually  ready  for  delivery  before  the 
spares  order  has  been  proposed,  negotiated,  and  definitized.  We 
also  believe  that  greater  use  should  be  made  of  catalog  pricing;  the 
Air  Force  and  the  prime  contractor  or  the  prime  contractor  and  the 
subcontractor  should  negotiate  baseline  values,  subject  to  quantity 
and  annual  inflation  adjustments,  for  items  that  are  identified  as 
potential  spares  items.  This  is  a  much  shorter  process  than  the 
current  system  of  individually  pricing  and  negotiating  every  single 
spares  order. 


Simplify  Contract  Property  Procedures 
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equipment  can  be  provided  from  surplus  stock.  On  the  AWACS  program, 
we  have  provided  over  500  such  notifications  in  the  past  2  1/2 
years;  we  have  never,  in  the  history  of  the  program,  received  a 
single  piece  of  special  test  equipment  from  the  government.  Aero¬ 
space  Industry  Association  (AIA)  ran  a  survey  recently.  They 
checked  14  companies,  over  a  period  of  five  years,  and  identified 
22,000  STE  notification  requests,  only  29  items  were  actually 
received  as  GFP,  worth  $150,000.  It  is  clear  that  the  STE  notifica¬ 
tion  process  has  no  economic  justification.  and  should  be 
eliminated. 


We  also  believe  that  the  GFE  repair  process  can  be  significantly 
reduced  in  complexity.  Linder  our  current  contract  with  the 
government,  we  have  processed  over  335  work  requests  to  repair 
defective  GFP;  over  50%  of  these  requests  have  been  under  $5,000. 
We  believe  that  most  of  these  repairs  can  be  priced  on  a  concept 
similar  to  inscope  changes.  For  years,  we  have  had  clauses  in  our 
contracts  that  state  that  any  change  that  can  be  accomplished  for 
less  than  $100,000  is  to  be  accomplished  at  no  change  in  price;  we 
can  certainly  implement  a  similar  procedure  for  repair  of  government 
property. 


Make  Greater  'Jse  of  Contractor  Enginee^inc 


Inspection  Personnel 


The  tenth  recommendation  is  that  the  Air  Force  use  designated 
engineering  representatives  (DER's)  and  designated  manufacturing 
inspection  representati ves  (DMIR's)  in  a  fashion  similar  to  that 
used  on  commercial  aircraft  programs.  The  Federal  Aviation 
Administration  has  established  procedures  whereby  contractor 
employees  can  be  designated  to  do  many  in-process  reviews  and 

approvals  required  in  the  commercial  airplane  certification  process. 
The  commander  of  AFSC,  recently  announced  a  shortage  of  over  700 

engineers  in  the  Air  Force  Systems  Command.  We  believe  that  many  of 

those  shortages  could  be  eliminated  by  a  system  similar  to  that  used 
by  the  FAA.  We  proposed  using  the  Saudi  tanker/cargo  program  as  a 
test  case  to  use  contractor  personnel  for  interim  inspections  and 

interim  approvals  in  lieu  of  Air  Force  engineering  or  inspection 
personne  1 . 


Use  Contractor 
Capability 


Maintenance 


Organic  Depot  Reoair 


The  final  recommendation  is  to  expand  the  use  of  contractor 
maintenance  in  lieu  of  organic  depot  repair  capability,  especially 
in  those  cases  involving  the  use  of  commercial  hardware,  on  programs 
that  are  small  in  quantity,  or  on  programs  that  use  complex 
technology  hardware  that  is  likely  to  change  or  become  obsolete  in  a 
short  time  period.  The  investment  that  has  been  made  in  developing 
organic  depot  repair  capability  often  is  one  of  the  major 
constraints  against  changing  hardware  that  has  become  obsolete  or 
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that  presents  serious  operations  and  maintenance  problems.  On  the 
AWACS  Program,  we  have  been  able  to  identify  an  investment  in  excess 
of  S300  million  that  has  been  made  to  handle  annual  repair  costs  of 
about  $16  million.  We  believe  that  this  investment  is  excessive  and 
that  substantial  savings  could  be  made  by  selective  use  of 
contractor  maintenance  in  many  areas. 

CONCLUSION 

All  of  the  areas  covered  by  these  eleven  recommendations  have  been  mentioned 
in  other  studies  in  the  past.  The  Defense  Science  Board  has  a  series  of 
studies  going  back  some  ten  years  dealing  with  most  of  these  subjects.  There 
have  been  recommendations  by  the  Aerospace  Industry  Association  to  the 
Defense  Department  covering  many  of  these  subjects.  The  Air  Force  Systems 
Command  conducted  an  extensive  study  at  Boeing  in  1981  comparing  commercial 
and  military  procurement  practices;  it  also  covered  many  of  these  same  areas. 
While  none  of  the  ideas  may  be  new,  we  believe  that  there  is  merit  in 

pursuing  them  and  in  making  changes  to  the  contract  to  effect  significant  cost 
savings. 

We  believe  strongly  that  these  changes  can  result  in  significant  savings  and 
that  the  added  risks  are  small  and  certainly  cost  effective.  However,  in 
order  to  implement  these  changes,  it  will  be  necessary  to  receive  top  level 
support  from  the  Defense  Department  and  the  Air  Force.  None  of  these 
recomnendations  can  be  implemented  at  the  working  level.  They  require  waivers 
to  directives  and  policies;  they  will  require  waivers  to  the  Defense 

Acquisition  Regulations  (DAR)  and,  in  some  cases,  waivers  or  changes  to 
statutory  requirements.  There  will  be  a  tremendous  amount  of  bureaucratic 
pressure  against  implementing  the  recommended  changes. 

Management  decisions  can  and  should  be  made  by  the  Air  Force  to  implement 

these  cost  effective  recommendations.  ~  This  is  directly  responsive  to 
President  Reagan's  recent  executive  order  directing  that  all  Federal 

departments  implement  procedural  revisions  to  reduce  government 
administrative  costs  and  the  AFSC  "War  on  Costs".  We  have  suggested  use  of 
the  AWACS  program  as  a  test  case  and  have  made  a  commitment  to  the  Air  Force 
that  we  will  submit  proposals  reflecting  these  savings  and  that  we  will  pass 
on  savings  that  we  can  negotiate  with  our  subcontractors.  It  is  our  intention 
to  pursue  this  as  long  as  the  Air  Force  indicates  an  interest  in  implementing 
cost  effective  changes  to  government  procurement  practices. 
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Procurement 

Practices 

Study 


M.  E.  Brislawn 
May  24,  1983 


BACKGROUND 

Organizational  depth  studies  -  mid  1 98 1 

•  Company  wide 

•  Reduce  overhead  and  management  costs 

Cahucci  request  -  Oct  1981 

•  "Eliminate  costly  and  unnecessary  practices" 

Procurement  Practices  Study 

•  Final  report  •  Feb  1982 

•  Reviewed  with  ESD,  AFSC 

•  Contract  Proposals  •  starting  June  1 982 

•  Will  reduce  contract  price 
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30  argali  jjt  inn  reviews,  wnith  •**  c*l’  depth  studies,  were 
•  1**d  «t  reducing  Cverheed  end  r^neoenent  costs.  We  h«wt  elso 
Initiated  •«  In-depth  e>ft""n«t1on  of  tht  tffort  required  In 
performing  •  «ijor  weapons  svste*  contract.  The  f- 3A  ( AwACS I 


OBJECTIVE  AND  APPROACH 


Objective 

•  Reduce  product  costs  by  simplifying  procurement  practices 
without  deterioration  of  product  performance,  quality  or 
operating  costs 

Approach 

•  Selected  E-3A  Program  as  test  case 

•  Conducted  detailed  evaluation  of 

217  terms  &  conditions 
318  mil-specs  &  standards 
566  specifications 
375  contract  data  items 

•  Compared  commercial  and  military  practices 


E-3A  PROGRAM  BACKGROUND 

Long,  stable  program: 

•  Development  began  in  1970 

•  Production  authorized  in  1975 

•  Production  expected  until  early  1 990’s 

Good  history  of  cost  consciousness: 

•  Specifications  tailored  to  take  advantage  of  commercial 
707-320  production  base 

•  Multi-year  approach  used  on  U.S.  FY  '80  *  83  and  NATO 

•  Numerous  cost  reduction  suggestions  implemented 

Still  room  for  improvement 

•  Continue  internal  cost  reduction  program 

•  Seek  USAF/DOD  support 
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FINDINGS 


1)  Management  reporting: 

•  Requirements  not  associated  with  risks 

•  Monthly  cost  reporting  on  1 ,000  cost  accounts  per  contract 

•  Performance  on  10-20,000  events,  some  as  low  as  $5,000 

•  Variance  analysis  on  no  longer  correctable  events 

2)  Follow-on  procurement  requirements; 

•  40,000  pages  for  U.S./NATO  integrated  program  -  plus  1 5,000 
pages  of  specs 

•  5  C/SCSC  reviews  since  1 980 

3)  Cost  and  pricing  evaluation  of  subcontractors: 

•  Cost  versus  price  analysis 

•  Approximately  200  a  year  required  for  subsystem  suppliers 

•  Imposed  on  airframe  suppliers  with  25  years  of  history 


RECOMMENDATIONS 

1)  Tailor  management  reporting 

•  Exception  reporting 

•  Frequency  of  reporting 

•  Level  of  reporting 

2)  Simplify  follow-on  procurement  requirements 

•  Cost  proposals 

•  Other  proposal  documentation 

•  Implementation  reviews 

3)  Concentrate  cost  and  pricing  evaluation  on  high  risk 
subcontractors 
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FINDINGS 


4)  Mandatory  contract  provisions: 

•  Thresholds  as  low  as  $2,500;  many  unchanged  for  20  years 

•  Many  companies  dropping  out  of  defense  work 

•  BAC  reporting  on  200  separate  contracts 

5)  Specifications: 

•  566  specs  under  Class  I  control  (85,000  pages) 

•  1 80  more  specs  added  for  Saudi 

6)  Change  processing; 

•  1 50  changes  a  year 

•  300  -  380  days  to  process 

•  One-third  of  administrative  personnel  work  changes 


RECOMMENDATIONS 

4)  Raise  thresholds  for  mandatory  contract  provisions 

•  Not  applicable  to  small  or  commercial  firms 

•  Company  wide  rather  than  individual  contract 

5)  Simplify  specifications 

•  Eliminate  CEI's  after  FCA 

•  Maintain  top  level  specifications 

6)  Simplify  change  processing 

•  Block  changes 

•  Parallel  reviews 
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FINDINGS 

7)  Contract  data: 

•  Each  contract  has  approximately  100  data  items;  (220  for  Saudi) 

•  1 67  different  offices  receiving  data 

•  Little  success  in  removing  data  items 

8)  Spares  ordering: 

•  Concurrent  releases  have  saved  20  ■  50% 

•  Contracting  takes  210  ■  240  days  -  longer  than  to  build  hardware 

•  Westinghouse  spares  pricing  agreement 

9)  Government  Property  Procedures: 

•  E-3A  has  never  received  GFE  from  STE  notifications 

•  AIA  survey  -  14  companies  over  5  years;  22,000  requests, 

29  items  received  of  GFP  ($1  50K) 

•  E-3A  has  processed  335  work  requests  -  50%  under  $5,000 


RECOMMENDATIONS 

7)  Reduce  contract  data 

8)  Streamline  spares  ordering 

•  Concurrent  ordering 

•  Catalog  pricing 

9)  Simplify  Government  Property  Procedures 

•  STE  notifications 

•  GFE  work  requests 
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FINDINGS 


10)  Designated  engineering/manufacturing  representatives: 

•  General  Marsh  announced  a  shortage  of  700  engineers  in  AFSC 

•  FAA  full  time  support  for  727/737/747  production  and 
757/767  development 

40  FAA  engineers/215  DER's 
9  FAA  inspectors/ 41  DMIR's 

1 1 )  Organic  maintenance: 

•  S300M  investment  for  E-3A  for  annual  repair  costs  of  $16M 

•  4200  reparables  on  AWACS  Program 

2300  never  repaired 
1 300  -  <  1  repair  per  year 
60  •  >  1  repair  per  month 

4%  of  parts  account  for  45%  of  field  repair  cost  and  70%  of 
depot  repair  cost 


RECOMMENDATIONS 

1 0)  Use  designated  engineering  representatives  and  designated 
manufacturing  inspection  representatives 

1 1)  Use  contractor  maintenance  in  lieu  of  organic  depot  capability  for: 

•  Commercial  hardware 

•  Small  quantity  programs 

•  Complex  technology  areas 
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OTHER  STUDIES 


Tailor  Mgmt  Reporting 

Simplify  Follow-on 
Procurements 

Limit  Subcontractor 
Evaluations 

Raise  Thresholds  • 
for  Suppliers 

Minimize  Spec  Maint 

Simplify  Change 
Processing 

Reduce  Contract 
Data  Lists 

Streamline  Spares 
Simplify  ST/STE  &  GFE 
Use  Designated 
Representatives 

Use  Contractor  Maint 


OSB  1973  USB  1977  USB  1979  DS8  1980  SaKV)S  CP*19H1JDV 
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CONCLUSIONS 


Recommended  changes  can  result  in  significant  savings 
Changes  are  cost  effective  -  little  added  risk 

Top  level  support  is  required 

•  Directives  and  Air  Force  policies  and  regulations 

•  Defense  acquisition  requlations 

•  Pressure  from  "cuitists" 

Secure  waivers  pending  regulation  changes 
Proposal  commitment 

•  Boeing  has  submitted  eight  (8)  proposals  reflecting  savings 

•  Will  pass  on  any  savings  negotiated  with  suppliers 
Industry  support  required 
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DEVELOPMENT 

OF 

CONFIGURATION  MANAGEMENT 
AT  THE 

SPACE  TELESCOPE  INSTITUTE 


25th  Annual  ADPA-TDC 
r^tP:  74  -  7ft  MAY  1985 
Presenter:  M.  A.  Dahiels. 


SPACE  TELESCOPE  CONFIGURATION 


HIGH  G*»NANl|NNA 


SBCE  TELESGOFE  SCIENCE  INSTITUTE 


Date:  24 
Presenter. 


-  26  HAY  j 
M-  A.  Dam: 


THE  SPACE  TELESCOPE  SYSTEM 
CONTROL  ORGANIZATION 


NASA  HO 

NASA  -  MARSHALL  (MSEC) 

NASA  -  6ODDAR0  (GSFC) 


o  THE  ST  SYSTEM 

o  THE  TELESCOPE 
o  INSTRUMENTS 

o  DATA  CAPTURE 
o  DATA  PROCESSING 
o  TRACK I N6/C0MMAND 


SPACE  TELESCOPE  INSTITUTE  (ST  Scl) 


o  GROUND  DATA  PROCESSING 
o  ASTRONOMICAL  OBSERVATORY 
o  SCIENCE 


THE  ST  Sci 


o  INDEPENDENT  ORGANIZATION  OF  AMERICAN  UNIVERSITIES  FOR  RESEARCH  IN 
ASTRONOMY  (AURA) 

o  RESPONSIBLE  TO  MAXIMIZE  SCIENTIFIC  RETURNS  FROM  THIS  PROGRAM 

-  PROVIDE  REQUIREMENTS  AND  LEASE  FACILITY 

-  DEVELOP  A  GUIDE  STARS  SELECTION  SYSTEM  (6SSS) 

-  DEVELOP  A  SCIENCE  DATA  ANALYSIS  SYSTEM  (SDAS) 

-  OPERATE  A  SEPARATELY  DEVELOPED  SCIENCE  OPERATIONS  GROUND  SYSTEM  (SOGS) 


o  SCIENCE  OPERATIONS  FOR  SPACE  TELESCOPE 


CM  REQUIREMENTS 


SB*CE  TELESCOPE  SCIENCE  INSTITUTE 


ST  Scl  CM  REQUIREMENTS 


NASA  CONTRACT  REQUIRES  ST  Scl  TO  IMPLEMENT 
o  CM  SYSTEM  FOR 

•  PRODUCTS  (GSSS.  SDAS,  BUSINESS  SYSTEM) 

-  GFM  ITEMS  (SOGS) 

-  'PRIVATELY'  DEVELOPED  ITEMS  (FACILITY,  HARDWARE) 
o  DATA  REQUIREMENTS  DOCUMENT  (DRD)  SYSTEM 

o  COMPLY  WITH  CM  STANDARDS 

-  D0D-STD-480A 

-  RlL-STQ-490 

-  MIL-STD-I300 

-  D0D-D-10008 

•  NASA  GSFC  GM1  8040. 1A 

-  GSFC  SPACE  TELESCOPE  PROJECT  CM  PUN 


SB*CE  TELESGOFE  SCIENCE  INSTITUTE 


st  si  i  a  aim 


Date: 


24  -  26  I 

Bf:  ^ "  A« 


o  6SSS  (HU  AND  SU  -  INTEGRATED) 

o  SDAS  (SN) 
o  SOGS  (SU) 
o  FACILITY 

o  BUSINESS  SYSTEM  (HU  (  SU) 

o  COMPUTERS  (HARDUARE) 

o  DRD 


■45,000  LINES  OF  CODE 
2  M I CRODENS I QMETERS 

-50,000  LINES  OF  CODE 

-60,000  LINES  OF  CODE 

LEASED  BUILDING  CONSTRUCTED 
AND  MAINTAINED  TO  SPECS 

PRIME  550-11  COMPUTER 
FINANCIAL  PACKAGE 
VISION  (DECISION  SUPPORT  SYSTEM) 
INFO  (DATA  BASE  MANAGEMENT) 

2  VAX  11/750 
2  VAX  11/780 

43  FORMAL  DOCUMENTS. 


CM  IMPLEMENTATION  PROBLEMS 


o  GR0UIN6  PROJECT 

-  ALL  REQUIREMENTS  NOT  KNOUN 

-  SOME  REQUIREMENTS  NOT  PRECISE 

-  STAFFING  FUNDED  INCREMENTALLY  (LATE) 

-  MUST  LIVE  BY  SOME  'UNEDUCATED*  EARLY  CM  PROCEDURES 

o  STAFF  CM  ORIENTATION  INADEQUATE 

-  MAJOR  PORTION  FROM  ACADEMIA 

-  PROGRAMMER  COMPLEMENT 

o  OTHER 


EQUIPMENT  NOT  IN  PLACE 
NON-CENTRALIZATION  IN  SOFTUARE  DEVELOPMENT 
COMPLEX  INTERFACES 


CONTROL  AND  ORGANIZATION 


25th  Annual  ADF 


SB^CE  TELESCOPE  SCIENCE  INSTITUTE 


LEVELS  QF  CM  CONTROL 


rw  2A  -  26  HA> 
Presenter  M*  A.  fl / 


NASA  HO 

LEVEL  1 

MSFC 

LEVEL  II 

GSFC 

LEVEL  III 

ST  Sc  I 

LEVEL  IV 

PRODUCT  TEAMS 

LEVEL  IVA 

SUBCONTRACTORS 

LEVEL  V 

CB/M  ORGANIZATION 


o  CM  OFFICER 
o  QA  OFFICER 
o  SECRETARY 
o  PRODUCT  LEVEL  CH/OA 


(FUNDED  AFTER  1  YEAR) 

(FUNDED  AFTER  2  YEARS) 

(SHARED  WITH  PROG RAN  MANAGEMENT) 
(LEVEL  IVA  ASSIGNEES) 
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SB*CE  TELESCOPE  SCIENCE  INSTITUTE 


25th  Annual  ADPA-TDC 


Date  2A  -  26  HAY  1983 
ProMutw.  M«  A.  Daniels 

CM  CONTROL  ACTIVITIES 

o  CONFIGURATION  MANAGEMENT  PLAN 
o  CONFIGURATION  CHANGE  REQUEST  (CCR) 
o  CONFIGURATION  CONTROL  BOARD  (CCB) 

-  CLASS  I.  CUSS  II  CCR 

-  CCB  DIRECTIVES 

-  CCB  RECORDS 

o  ASSIST  LEVa  IVA  BASELINING  AND  IDENTIFICATION 
o  STATUS  ACCOUNTING  (DATA  BASE  SYSTEM) 

o  AUOITS  (INTERNAL,  BY  GSFC) 

o  DRD  CONTROL  AND  RELEASE 


o  INTERFACE  DOCUMENTS  COORDINATION 
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Uriannt  Timothy,  Director  Program  Management 
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o  STAFF  SHALL  -  TYPING  WORKLOAD 
o  AUTOMATED  SYSTEM  -  BEST  SOLUTION 
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Revision  of  CCR  002 

003  1  3  82-04  12/20/82 

Proposed  Cbg.  to  Funct.  Spec.  NAS5-2655S 

004  1  3  82-04  12/20/82 

Changes  to  30-03,  Vol  2  SDAS  Req. 

005  2  4  83-01  02/10/83 

30-04,  Vol.  2  Revision 

006  2  4  83-02  03/07/83 

S0-03  SOA 3,  Vol.  3  Design 

007  1  3  83-02  03/07/83 

Prop.  Changes  to  S0-03,  Vol.  2,  Requirements 
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02/22/83 

Implemented  -  Continuous  Implementation 
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Level 
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Level 
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Level 
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82011C 
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Level 
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82013C 
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Level 
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1.  This  report  does  not  Include  recurring  Items,  such  es  the  MA-01,  HA-01,  CO-01,  nor 
special  studies,  analysee  and  I CD  Inputs. 

2.  All  baselined  DRDs  are  under  strict  CM  control  for  changes,  revision  and  release. 
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INTRODUCTION  -  The  NEW  JERSEY  is  one  of  the  four  IOWA  Class  battleships.  She 
displaces  58  thousand  tons,  is  887.6  feet  long,  108.2  feet  wide  at  the  beam 
and  has  a  38  foot  draught  fully  loaded.  With  the  exception  of  the  two 
Japanese  YAMATO  Class  battleships,  they  are  the  largest  ever  built.  (Figure  1) 

NEW  JERSEY  is  powered  by  four  Westinghouse  geared  turbines  which 
develop  212  thousand  horsepower,  the  steam  being  supplied  to  these  turbines  is 
from  eight  Babcock  and  Wilcox  boilers.  The  ship  can  make  in  excess  of  36 
knots,  she  is  the  fastest  non-nucellar  powered  major  combatant  in  the  world. 

The  NEW  JERSEY  carries  9  thousand  tons  of  fuel  which  relates  to  a  cruising 
range  of  5,000  miles  at  30  knots  or  15,000  miles  at  17  knots.  She  is  manned 
by  80  officers,  1600  enlisted  men,  2  marine  officers  and  42  enlisted  marines. 

The  armor  of  the  NEW  JERSEY  is  unsurpassed  in  any  ship  ever  built. 

The  main  armor  belt  is  12.1  inches  thick  and  encircles  the  entire  ship,  this 
belt  is  increased  to  13.5  inches  in  the  area  of  the  screws  to  protect  them 
from  torpedo  hits.  The  turret  faces  are  17  inches  thick,  the  top  of  the 
turret  is  7.25  inches,  the  sides  and  backs,  12  inches,  and  the  entire  barbette 
is  11.6  inches  thick.  The  main  armor  deck  is  6  inches  thick  and  extends 
throughtout  the  ship,  it  is  located  one  deck  below  the  main  deck.  The  conning 
tower,  both  the  fore  and  aft  fire  control  towers  are  17.3  inches  thick. 

The  ship  carries  three  3  Gun  16"/50  Turrets.  Each  turrets  weigh 
over  5,000  tons.  The  16"/50  gun  fires  a  projectile  which  has  an  average 
weight  of  2,000  lbs.  The  heavest  being  the  armor  piercing  at  2,700  lbs.  and 
the  lightest,  the  high  capacity  at  1,875  lbs.  In  addition  to  these  standard 
projectiles  the  gun  is  capable  of  firing  the  new  MK  19  anti-personnel  projec¬ 
tile,  this  projectile  contains  400  individual  bomblets.  Each  round  is  pro¬ 
pelled  by  a  660  lb.  powder  charge,  made  up  of  six  110  lb.  powder  bags,  each 
wrapped  in  a  wear  reducing  jacket  (these  jackets  were  developed  during  the 
Viet  Nam  Conflict  and  decreases  gun  wear  by  a  factor  of  10).  The  16"/ 50  has  a 
range  of  23  miles  and  with  the  new  rocket  assist  projectile,  that  is  under 
development,  40  miles. 

In  addition  to  the  16"/50  battery,  the  ship  has  six  5"/38  Twin  Gun 
Mounts.  The  projectiles  for  these  guns  come  in  a  variety  of  configurations 
such  as;  White  Phospherous,  Armor  Piercing,  High  Capacity,  Illumination  and  the 
rocket  assisted  projectiles.  Maximum  range  for  normal  projectiles  is  9  miles 
and  for  the  RAP,  15  miles.  Fuzing  for  these  projectiles  is  adapted  for  the 
mission  to  be  fired,  for  example;  infra-red  and  variable  time  fuze  (radar)  is 
for  anti-air  warfare;  base  detonating,  point  detonating  and  mechanical  time 
fuzes  for  surface  warfare  and  naval  gun  fire  support  missions. 

Anti  Ship  Missile  Defense  (ASMD)  is  provided  by  four  Phallanx, 
Close-In-Weapon-Systems  (CIWS).  These  systems  are  of  the  latest  technology, 
they  have  a  firing  rate  of  6,000  rounds  per  minute,  with  a  2  second  reaction 
time.  ASMD  is  also  provided  to  the  ship  by  eight  Super  Rapid  Blooming 
Outboard  Chaff  Rocket  launchers  for  deception  purposes  and  the  latest  in 
electronic  counter  measure  equipments. 
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A  new  offensive  punch  has  been  added  to  the  NEW  JERSEY  in  the  form  of 
cruise  missiles.  She  carries  32  TOMAHAWK  missiles  and  16  HARPOON  missiles. 

The  TOMAHAWK  can  be  fired  at-sea  targets  up  to  400  miles  in  range  and  at  over¬ 
land  targets  at  1500  miles.  The  HARPOON  missiles  will  be  employed  against 
shipping  targets  out  to  200  miles.  Targeting  information  for  these  missile 
system  is  received  aboard  ship  by  a  form  of  the  Naval  Tactical  Data  System 
from  many  remote  sources. 

During  World  War  II  NEW  JERSEY  fired  771  rounds  of  16",  during  the 
Korean  War  she  fired  6,671  rounds.  By  contrast  during  the  short  120  day 
period  when  she  was  deployed  to  Viet-Nam  5,688  rounds  were  fired.  During  this 
same  period  she  also  fired  15,000  rounds  of  5". 

On  28  December  this  magnificant  man-o-war  was  recommissioned  for  the 
fourth  time  by  the  President  of  the  United  States. 

Mr.  A1  Signor  also  of  NSWSES  will  now  go  into  some  of  the  problems 
and  solutions  we  incountered  in  outfitting  the  NEW  JERSEY  with  the  documen¬ 
tation  required  for  operation  and  maintenance  of  the  ship  and  the  installed 
equipments  and  systems.  Upon  completion  of  his  presentation  we  will  show  a 
short  film  entitled  "American  Dreadnaught".  It  is  the  story  of  NEW  JERSEY  up 
to  her  entry  into  the  Viet-Nam  Conflict. 

TECHNICAL  DOCUMENTATION  -  The  Naval  Ship  Weapon  Systems  Engineering  Station 
was  tasked  by  the  Naval  Sea  Systems  Command  to  take  control  of  and  manage  the 
data  assets  for  the  Weapons  Department  of  the  USS  NEW  JERSEY.  (Figure  2) 

All  of  the  data  assets  were  sealed  in  the  Weapons  Department 
technical  library.  That  is,  the  hatchway  entrance  was  welded  shut.  A  crew  of 
personnel  from  the  shipyard  (Bremerton)  removed  the  data  from  the  shelves  and 
packed  it  into  72  boxes,  the  total  weight  being  approximately  5  tons. 

Much  of  the  data  contained  historical  as  well  as  still  classified 
documents.  Because  of  this.  Navy  regulations  required  the  data  be  accompanied 
by  a  guard  who  flew  on  the  same  commercial  airplane  and  stayed  with  the 
material  while  it  was  transferred  to  a  waiting  Navy  van  at  Los  Angeles  for 
transportation  to  Port  Hueneme.  He  then  accompanied  the  van  to  the  Station 
where  it  was  placed  under  guard  until  I  took  it  over. 

The  first  job  was  to  inventory  the  data  assets  to  determine  what  was 
available  and  to  establish  a  data  base  for  the  4  Battleships.  Since  the  NEW 
JERSEY  was  the  last  ship  of  its  Class  to  enter  the  mothball  fleet  (1969)  after 
the  Vietnam  war  it  was  felt  the  data  could  be  utilized  for  the  other  3 
Battleships  (Iowa,  Wisconsin,  and  Missouri).  (Figure  3) 

There  were  approximately  867  different  publications  ranging  from  an 
old  MK  1A  Gun  Computer  to  the  latest  on  the  16"/50  Caliber  Guns  in  the  three 
turrets.  In  some  cases  there  were  several  copies  of  the  same  publication. 
These  were  removed  and  forwarded  to  the  Naval  Ordnance  Station,  Louisville  for 
reprinting  and  further  distribution  to  the  various  commands. 
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Approximately  1,042  drawings  and  lists  of  drawings  were  contained  on 
35mm  microfilm  aperture  cards.  These  were  sorted  into  drawing  number  sequence 
and  a  print-out  made.  A  copy  of  this  listing  was  also  forwarded  to  the  Naval 
Ordnance  Station,  Louisville  for  review  and  for  establishing  a  new  microfilm 
data  package  for  the  Battleships. 

There  were  over  1,500  hard  copy  blueprints  inventoried.  Many  of 
these  had  been  revised  to  indicate  changes  to  the  equipments  made  by  Shipyard 
and  ship's  personnel.  A  listing  of  all  these  was  made  and  supplied  to  various 
users. 


In  addition,  there  were  many  files  of  correspondence  which  were  not 
only  of  historical  value  but  of  importance  concerning  shipboard  procedures  for 
maintenance  and  operations  of  the  gun  systems. 

Reprinting  of  many  of  the  publications  was  necessary  since  several 
were  "one-of-a-kind"  and  no  other  copies  existed.  The  reprints  were  necessary 
in  order  to  accomplish  the  necessary  training  and  establishing  of  a  publica¬ 
tions  library  for  the  other  Battleships.  (Figure  4) 

Several  of  the  publications  and  hard  copy  drawings  were  used  by  the 
Long  Beach  Naval  Shipyard  to  renovate,  replace,  and  repair  equipments  during 
the  renovation  and  installation  of  new  equipment  and  weapon  systems.  These 
were  marked  up  and  returned  to  the  ship  after  being  microfilmed. 

Also,  some  of  the  publications  that  were  reprinted  were  used  by 
contractors  and  navy  personnel  to  train  the  crews  on  the  various  gun  systems. 

Not  only  did  we  furnish  the  technical  publications,  but  in  the  case 
of  the  NEW  JERSEY  training  at  our  Seal  Beach  facility,  we  provided  the 
instructions  as  well.  We  taught  321  NEW  JERSEYMEN  over  2200  hours  of 
classroom  instructions  in  13  courses. 

The  courses  we  developed  for  this  effort  has  been  provided  to  Naval 
Training  Center,  Great  Lakes,  as  a  basis  for  their  course  development  for  the 
IOWA  crew.  We  also  taught  the  marine  detachment  operations  and  maintenance  of 
the  5"/38  twin  mount. 

The  Naval  Ordnance  Station,  Louisville  is  responsible  for  the  publi¬ 
cations  and  microfilm  of  the  engineering  drawings  for  all  the  gun  systems  and 
related  equipments. 

The  USS  IOWA  is  presently  undergoing  a  2  year  renovation  period  by 
the  Ingalls  Shipyard  at  Pascagoula,  Mississippi.  The  IOWA  has  a  long  way  to 
go  before  it  will  be  ready  for  re-commissioning.  Much  of  the  publications  and 
microfilm  of  the  engineering  drawings  is  being  supplied  to  the  shipyard  for 
the  renovation. 

Several  contractors,  J.  J.  McMullen,  EG&G,  etc.  are  all  using  the 
data  from  the  NEW  JERSEY  in  the  performance  of  their  studies  and  work  efforts 
in  the  renovation  program. 
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Training  of  ships'  personnel  has  been  accomplished  in  the  use  of  the 
microfilm,  publications,  and  drawing  files.  (Figure  5) 

A  new  dry-copier  reader  printer  was  supplied  to  the  ship  for  making 
instant  prints  from  the  microfilm.  Also  a  new  file  was  provided  for  the 
storage  of  the  microfilm. 

A  listing  of  all  the  publications  and  microfilm  was  supplied  to  the 
ship  from  the  inventory  records. 

PROBLEMS  -  There  is  a  lack  of  illustrated  parts  breakdowns  of  much  of  the 
equipment.  At  present  I  am  making  a  listing,  by  title,  of  all  the  parts  lists 
(Lists  of  drawings  and  Sketch  listings,  LDs  and  SKs)  and  showing  the  related 
listing  that  can  be  consulted  on  an  “as  needed"  basis.  (Figure  6) 

Some  of  the  microfilm  is  keypunched  on  the  aperture  card  different 
than  what  is  actually  on  the  document.  Several  are  punched  as  "LD12345"  when 
the  document  is  "SK12345".  It  is  intended  to  supply  this  listing  to  the  ship 
for  use  until  the  Naval  Ordnance  Station  is  able  to  supply  IPBs. 

The  Publications  Allownce  List  is  way  out  of  date  and  efforts  are 
underway  to  provide  an  updated  PAL  as  soon  as  possible. 

At  this  time  we  would  like  to  present  the  film  "American  Dreadnaught" . 
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PACKED  72  BOXES  (WEIGHING  APPROX  S  TONS)  OF  DATA  WHICH 
WERE  SEALED  IN  THE  WEAPONS  DEPARTMENT  LIBRARY 


•  REMOVED  FROM  SHIP  AND  FLOWN  UNDER  GUARD 
TO  LAX  -  LOADED  INTO  TRAILER  VAN  AND  DELIVERED 
TO  NSWSES. 


INVENTORIED  ALL  PUBLICATIONS,  MICROFILM 
AND  HARD  COPY  DRAWINGS 


•  APPROX.  867  DIFFERENT  PUBLICATIONS 

WITH  MULTIPLE  COPIES 

•  OVER  1,042  DRAWINGS  LISTS  ON  MICROFILM 

•  OVER  1,500  HARD  COPY  DRAWINGS 

•  MANY  LETTER  FILES  CONTAINING  HISTORICAL  DATA 


PROVIDED  PUBLICATIONS  AND  HARD  COPY  DRAWINGS  FOR 


•  REPRINTING  (FOR  IOWA,  WISCONSIN  &  MISSOURI) 

•  MODIFICATION/  REPAIR  OF  WEAPON  EQUIPMENTS 

•  INSTALLATION  OF  NEW  EQUIPMENT  (ELECTRONICS, 

HARPOON,  &  TOMAHAWK) 

•  TRAINING  AT  SEAL  BEACH,  NSWSES,  AND  GREAT  LAKES 

•  NAVAL  ORDNANCE  STATION,  LOUISVILLE 

•  PASCAGOULA,  MISSISSIPPI  YARD  FOR  U.S.S.  IOWA 

•  CONTRACTORS  WORKING  ON  PROGRAMS  FOR  THE  SHIP 


PROVIDED 


•  TRAINING  FOR  SHIPS’  PERSONNEL  IN  USE  OF  MICROFILM 

•  NEW  READER/PRINTER  AND  MICROFILM  STORAGE  CABINET 

•  LISTINGS  OF  ALL  THE  PUBLICATIONS  AND  MICROFILM 
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PROBLEMS 


LACK  OF  ILLUSTRATED  PARTS  BREAKDOWNS  OF 
OLD  EQUIPMENTS 

DATA  MOUNTEO  ON  MICROFILM  NOT  IDENTIFIED  BY 
CORRECT  DOCUMENT  NUMBER 

•  NSWSES  PRESENTLY  REVIEWING  AND  WILL  PROVIDE 
LISTING  OF  ALL  EQUIPMENTS  BY  PARTS  LIST  NUMBER 
AND  "WHERE  TO  FIND  IT" 

PUBLICATIONS  ALLOWANCE  LIST  NEEDS  TO  BE  UPDATED 


MANAGING  CHANGE  IMPLEMENTATION 
(Control  of  problems  after  change  release) 

by 


John  Nast 
NAST  &  Associates 


SUMMARY 

Implementing  changes  into  production  has  its  own  characteri stic 
problems.  (They  seem  to  be  multi  pied  by  the  rate  at  which  changes  are 
made . ) 

This  paper  presents  the  findings  of  a  recent  project  to  resolve  change 
management  problems  for  a  manufacturer  of  magnetic  computer  storage 
equipment.  Every  activity  in  Manufacturing  and  Quality  Assurance  were 
affected  by  configuration  control  problems  such  as  poor  planning,  not 
meeting  schedule,  surplus  and  shortages  of  material,  implementing 
changes  that  don't  work,  support  documents  not  available  with  first 
shipment,  not  knowing  the  correct  change  level,  etc.  The  app.-oach  used 
in  this  paper  may  be  tailored  to  resolve  similar  problems  in  other 
company  environments. 

Resolution  of  the  problems  requires: 

•  Motivated  people. 

•  Fully  coordinated  planning. 

•  Tracking  status  of  implementation. 

•  Effective  reporting. 

•  Corrective  action  when  needed. 

•  Clear  delegation  of  responsibilities, 
t  Documented  prpcedures . 
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INTRODUCTION 


About  ten  years  ago,  I  established  an  Engineering  Change  Control  System 
for  a  major  manufacturer  of  computer  equipment.  The  scope  of  the  project 
extended  only  to  distribution  of  microfilm  to  Manufacturing.  At  that 
time,  we  obtained  a  commitment  by  Manufacturing  that  they  would  document 
their  internal  procedures  for  Change  Review  and  Implementation. 

Late  in  1931  I  returned  to  resolve  some  production  problems,  primarily 
associated  with  the  implementation  of  changes.  (They  had  not  developed 
the  promised  procedures.)  This  paper  is  based  on  that  assignment. 

GENERAL  BACKGROUND 

Although  this  paper  is  based  on  a  coirmercial  application,  the  basic 
concepts  of  change  control  are  quite  similar  to  Government  Contracts. 

A  comprehensive  change  review  system  had  been  established  to  deter¬ 
mine  the  Design,  Production,  and  Field  impact  of  proposed  changes. 
Schedule,  cost,  and  technical  data  was  obtained  for  authorization  and 
was  also  used  to  establish  an  "Implementation  Date". 

After  sale,  the  product  is  installed,  maintained,  and  upgraded  by  the 
Manufacturer;  therefore,  the  logistic  aspects  of  their  change  control 
is  quit  a  similar  to  Government  programs. 

Production  requirements  were  oriented  to  meeting  a  schedule  and  did  not 
initially  include  the  internal  detail  needed  to  accomplish  it.  Except 
for  mature  products  that  seldom  change  and  small  companies,  procedures 
and  tracking  systems  are  needed. 

CHARACTERISTICS  OF  CHANGE:  SLIDE  1 

Product  Stability/Sensitivity  influences  change  type,  frequency,  and  the 
probability  of  introducing  new  problems  when  old  ones  are  solved. 

•  Is  the  product  Design  Sensitive?  How  much  testing  is  needed?  Does 
it  include  subtle  interrelationships  among  parts  and  functions?  Is 
the  design  very  complex? 

•  Is  it  Process  Sensitive?  Does  the  yield  change  significantly  from 
small  variations  in  process,  environment,  or  material?  Is  imperical 
fine  tuning  of  processes  needed  to  make  them  work? 

•  Is  it  Application  Sensitive?  Do  subtle  differences  in  how  it's  used 
cause  it  to  perform  poorly?  Are  there  subtle  interrelationships 
among  components  of  its  using  system? 

An  inherently  Stable  product  has  none  of  these  Characteristics  and  does 
not  tend  to  have  many  problems  implementing  changes. 

Computer  equipment  however,  is  generally  sensitive  in  all  areas,  a  cost 
for  complex  systems  using  advanced  state-of-the-art. 
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NEED  AND  URGENCY  OF  CHANGES 

In  the  large  frame  computer  business,  changes  are  a  fact  of  life.  They 
are  numerous  and  often  needed  yesterday.  Changes  are  needed  to: 

•  Avoid  stopping  production, 

•  Correct  problems  that  seriously  affects  the  customer. 

•  Improve  performance  or  introduce  new  bells  and  whistles  to 
satisfy  competitive  marketing  requirements. 

•  Reduce  cost  and  resolve  availability  problems. 

The  urgency  and  frequency  of  changes  made  it  impractical  to  implement 
changes  in  blocks  or  at  specified  phase-in  points.  In  this  situation, 
each  change  has  to  be  individually  iplemented. 

IMPLEMENTATION  PROBLEMS  SLIDE  2 

This  paper  presents  technicques  used  for  managing  implementation  in  this 
environment  in  a  way  that  minimizes  problems  such  as: 

•  Scheduling:  Impossible  dates,  overlooked  tasks,  missed  completion 
dates  and  a  number  of  other  problems  can  result  from  poor  planning. 

•  Unexpected  Delays:  Procurement  or  engineering  activity  not  meeting 
schedule  may  delay  implementation. 

•  Overloaded  Capacity:  A  frequent  consideration  when  quantities  of 
retrofit  kits  are  involved.  The  resulting  surge  can  tax  caoacity. 

•  Unanticipated  Scrap/Surplus:  Caused  by  a  number  of  things,  among 
them  is  not  meeting  a  change  implementation  schedule. 

•  Unproven  Changes:  If  changes  don't  work  as  intended,  there  is  a 
risk  of  stopping  production.  Without  adequate  testing,  a  design 
or  process  change  may  introduce  more  problems  than  it  solves. 

•  Production  Schedule  Problems:  Implementation  Plans  based  on  stock 
usage  must  b''  revised  if  Production  schedule  changes  or  isn’t  met. 

•  Inadequate  Process  Controls:  Changes  to  process  must  be  controlled, 
The  need  for  control  is  related  to  the  sensitivity  of  the  process. 

•  Sequence  of  Implementation:  Related  changes  must  be  coordinated  so 
that  they  are  implemented  in  the  correct  sequence,  especially  in 
design  or  application  sensitive  products. 

•  Correct  Production  Change  Level:  Production  and  Quality  personne. 
must  know  the  correct  change  level.  The  difference  between  "lates\. 
change"  and  "currently  in  production"  must  be  understood,  the 
latest  change  may  not  be  implemented  for  months. 

•  Unacceptable  Field  Deliveries:  Retrofit  kits  and  spares  should  be 
available  when  the  first  revised  unit  ships.  Creative  planning  is 
often  required  to  approach  this  goal. 
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SYMPTOMS  vs  PROBLEMS 


SLIDE  3 


The  list  is  long  and  varied,  but  the  initial  realization  is  that  it  is 
not  a  list  of  problems.  It  is  a  list  of  SYMPTOMS!! 

SLIDE  3 

Each  item  listed  results  from  one  or  more  deficiency  shown  here: 

But  again,  this  is  a  list  of  SYMPTOMS.  By  repeating  this  analysis  we  can 
move  progressively  closer  to  the  root  cause  until  responsibility  for  the 
appropriate  corrective  action  becomes  clear. 

IT  IS  APPARENT  THAT  THE  COMPANY  DOES  NOT  ADEQUATELY  MANAGE  CHANGE. 

!!!  AND  MOST  DON'T!!! 

REQUIREMENTS  FOR  MANAGING  IMPLEMENTATION:  SLIDE  4 

The  basic  requirements  for  managing  change  implementation  are: 

•  PEOPLE:.  Trained,  qualified,  understanding,  motivated  employees  are 
a  must.  A  prime  responsibility  of  management. 

•  PLANNING:  Fully  coordinated  planning  provides  a  baseline  to  manage. 
Only  in  small  companies  can  control  be  maintained  without  a  plan. 
Responsibility  is  divided  among  the  Systems  Design,  Participating 
Personnel,  the  Planner,  and  Management. 

•  STATUS  TRACKING:  Change  associated  activities  must  be  monitored  to 
assure  that  the  plan  is  being  met,  or  to  identify  any  potential 
problems  as  early  as  possible.  Tracking  is  the  responsibility  of 
the  system  design  and  the  people  that  operate  it. 

•  REPORTING:  Personnel  and  management  must  be  kept  informed.  Reports 
are  needed  that  identify  status,  measure  performance,  show  trends, 
identify  problems,  and  notify  personnel  of  changes.  Effective 
reporting  is  a  system  design  responsibility. 

•  MANAGEMENT:  Informed  Management  must  understand  the  system  and 
their  responsibility  to  assure  that  personnel  do  not  drop  the  ball. 

PEOPLE: 

People  are  listed  first  because  they  are  most  important!  Good  people  can 
make  a  poor  system  effective-,  the  best  system  in  the  world  is  useless  if 
the  people  operating  it  are  not  motivated  or  do  not  understand  their 
joos.  Not  only  do  people  need  to  understand  their  job,  they  must  also 
understand  how  their  job  contributes  to  the  overall  operation  of  the 
system  and  the  Company.  From  this,  they  must  have  a  strong  sense  that 
they  are  making  a  significant  contribution.  To  accomplish  this  you  need: 

t  Efficient,  well  documented  procedures. 

•  Training,  specifically  directed  at  the  needs  of  the  personnel. 

t  Management  that  understands  the  system,  and  the  ART  of  Motivation. 
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If  management  doesn't  care,  no  one  else  will.  Personnel  get  their  pri¬ 
orities  and  attitudes  either  directly  or  indirectly  from  their  managers. 
This  includes  maintaining  the  sensitive  balance  between  involvement  and 
delegation.  Managers  must  also  be  trained  in  the  system,  with  less 
operating  detail  but  a  more  global  understanding. 

An  often  overlooked  problem  is  the  need  of  most  employees  to  feel  that 
they  are  working  efficiently.  When  unnecessary  or  inefficient  operations 
waste  their  time,  they  feel  that  since  no  one  cares  so  why  should  they. 
There  are  several  answers  to  this  problem: 

•  Eliminate  unnecessary  steps  from  procedures  or  streamline  ineffi¬ 
cient  activities.  (This  need  even  creeps  into  the  best  procedures 
after  changes  in  the  company  eliminate  or  significantly  change  the 
original  requirement.  There  is  also  a  tendency  to  solve  problems 
by  adding  steps  instead  of  correcting  the  root  cause.) 

•  Improve  efficiency  where  it  can  be  done.  New  technology  may  often 
provide  an  answer,  but  sometimes  an  old  approach  may  be  the  best. 
Other  times  a  few  simple  changes  in  how  or  when  an  operation  is 
done  will  work  wonders. 

•  Problems  from  a  lack  of  understanding  can  usually  be  resolved  by 
education.  If  employees  are  expected  to  do  an  unpopular  operation, 
they  will  do  it  better  if  they  understand  why  it  must  be  done. 


IMPLEMENTATION  PLANNING 

Change  implementation  involves  parallel  and  unconnected  activity  by 
several  functions.  Without  their  close  coordination: 

•  Materials  may  be  scheduled  into  production  long  before  the  tooling 
is  available. 

•  A  new  assembly  may  be  scheduled  into  production  months  before  a  new 
hybrid  component  is  available,  or  its  test  fixture  and  program  are 
ready  for  use. 

•  Q  A  may  inspect  or  test  parts  to  the  wrong  change  level. 

•  Materiel  problems  may  arise,  such  as: 

+  Simultaneous  shortage  and  surplus,  caused  by  no  implementing 
the  change  on  the  date  anticipated  by  requirements  planning. 

+  Missing  the  implementation  date  because  changes  to  the  produc¬ 
tion  schedule  were  not  reflected  in  the  plan,  or  production  is 
not  on  schedule. 

In  order  to  assure  that  all  these  activities  occur  as  planned,  changes 
must  be  managed  as  mini -projects ! 


ACCUMULATION  OF  DATA: 
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During  Review  of  a  change,  Customer  Support,  Manufacturing,  and  Quality 
Assurance  review  each  change  for  technical  content,  and  to  identify  its 
cost  and  schedule  impact. 

The  procedure  is  fairly  simple!  Copies  of  the  proposed  change  are  sent 
to  a  Change  Coordinator  in  Manufacturing  and  in  Customer  Support.  They 
coordinate  the  proposal  throughout  their  respective  organizations  in 
order  to: 

•  Identify  and  Resolve  any  potential  technical  problems. 

•  Obtain  technical  concurrence. 

•  Obtain  cost  and  schedule  schedule  data. 

•  Prepare  a  plan  for  implementation. 

In  Manufacturing  the  coordination  includes  Process,  Test,  and  Quality 
Engineers,  Production  Control  Analysts,  Planner/Buyers,  and  OEM  Customer 
Coordinators.  The  Manufacturing  Change  Coordinator  also  negotiates  with 
Customer  Support  to  establish  a  schedule  for  delivery  of  spare  parts  and 
retrofit  kits. 

This  review  is  done  by  individuals  who  know  most  about  what  is  required 
to  implement  the  change,  the  problem  is  to  be  sure  that  they  provide  all 
of  the  data  that  is  needed. 

FORMS  USED 

Materials  Data:  SLIDE  6 

The  Production  Control  Analysts  and  Planner/Buyers  use  a  sheet  of  the 
Parts  Affected  Formset  to  accumulate  the  information  that  they  must 
provide. 

Stock  status,  usage  rate,  projected  depletion  of  stock,  standard  cost, 
lead  time,  etc.  is  usually  needed.  Change  data  may  also  involve  supplier 
costs,  leadtime  committments,  and  other  related  issues. 

Technical  Activities  SLIDE  7 

For  Manufacturing,  Test,  and  Quality  Engineers  the  required  data  is 
obtained  from  a  Worksheet  that  acts  as  a  memory  jogger  to  assure  that 
everything  is  considered,  and  as  a  place  to  make  notes  as  the  change  is 
reviewed. 

The  top  is  filled  in  by  the  Change  Coordinator  and  used  to  distribute 
the  form  with  a  copy  of  the  change  package.  It  is  sent  to  the  engineers 
associated  with  parts  or  processes  included  in  the  proposed  change. 

The  next  area  on  the  form  is  used  by  the  Reviewer  to  indicate  technical 
concurrence  or  to  note  any  exceptions. 


The  EC  Planning  and  Cost  Data  blocks  provide  a  place  to  list  any  Process 
Instructions  or  Programs  to  be  changed  or  created,  time  to  rework  parts, 
and  time  needed  to  revise  instructions  and  programs.  Note  there  are  two 
kinds  of  estimates,  time  in  hours  to  do  the  job,  and  schedule  time  to 
process  the  documents  or  media  and  have  them  available  to  the  floor. 

The  next  area  is  for  cost  &  schedule  data  related  to  revision  or  acqui¬ 
sition  of  equipment  or  tools;  including  design,  procurement,  building, 
and  validation. 

At  the  bottom  are  blocks  to  define  the  effect  of  the  change  on  product 
cost,  and  a  block  for  notes  on  testing  or  validation  requirements. 

Each  Manufacturing,  Test,  and  Quality  Engineer  fills  in  this  data  during 
review  and  turns  it  in  at  a  technical  review  meeting. 

After  the  schedule  is  completed,  the  Change  Coordinator  adds  the  due 
dates  to  the  form  and  returns  a  copy  to  the  initiators  department. 

Supplier  Data  SLIDE  8 

Supplier  coordination  can  be  another  source  of  problems.  On  ocasion  it 
is  necessary  to  coordinate  a  proposed  change  with  a  supplier.  It  may  be 
for  technical  review,  a  revised  price,  a  schedule  committment,  identify 
one  time  costs,  or  any  of  several  other  reasons. 

The  main  difficulties  are,  assuring  that  the  supplier  understands  that 
he  is  reviewing  a  PROPOSED  change,  and  asking  him  the  right  questions. 

This  form  is  designed  to  ask  most  of  the  necessary  questions  for  up  to 
four  revised  parts.  It  provides  space  to  disposition  up  to  three  POs 
per  part,  to  cover  times  when  more  than  one  PO  has  been  issued. 

A  real  danger  with  involving  the  supplier  at  this  time  is  his  misunder¬ 
standing  your  intent.  He  must  clearly  understand  that  the  change  is  NOT 
to  be  implemented  until  authorized  by  PO.  A  note  on  the  face  of  the  form 
states: 

"This  is  a  proposed  change.  Take  no  action  to  implement  this  change 
until  it  is  covered  by  P.O.". 

Form  instructions  on  the  back,  and  a  cover  letter  include  the  statement: 
"This  is  a  proposed  change  package  that  is  being  reviewed,  the 
change  may  or  may  not  be  authorized.  If  authorized  it  may  or  may 
not  be  the  same  as  documented  in  this  package." 

However,  more  than  once,  a  vendor  has  implemented  the  change  too  soon. 

One  major  supplier  explained  to  me  with  pride  how  he  delivered  revised 
parts  a  month  before  the  commit  date  on  the  P.O..  It  took  me  a  half  hour 
to  convince  him  that  he  was  not  doing  us  a  favor.  He  had  no  idea  that 
the  change  he  was  making  had  to  be  implemented  concurrently  with  other 
changes.  You  can  imagine  the  problems  that  that  caused. 

GOOD  COMMUNICATION  U1TH  SUPPLIERS  IS  NECESSARY  TO  MINIMIZE  PROBLEMS 
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CHANGE  IMPLEMENTATION  SCHEDULE 


SLIDE  9 


Here  is  a  typical  implementation  plan  for  a  fairly  simple  change. 

Engineering  frequently  asks  why  it  takes  so  long  to  implement  a  change. 
Many  don't  realize  that  there  can  be  a  complete  design,  procurement, 
fabrication,  and  test  cycle  between  release  of  a  change  and  implementa¬ 
tion  into  production.  This  slide  represents  the  implementation  schedule 
for  the  release  of  a  new  circuit  board.  It  includes  only  the  activities 
associated  with  the  procurement  of  a  new  fabricated  board  and  its 
subsequent  assembly. 

•  There  are  Inspection  Instructions  for  receiving  inspection  of  the 
fabricated  board  and  for  acceptance  of  the  finished  assembly. 

•  Manufacturing  Instructions  and  programming  for  auto-insertion  are 
needed  to  assemble  it. 

•  A  new  Test  Procedure  and  Program  are  needed  to  test  the  assembly. 

t  Changes  are  also  required  to  Process  Documents  for  the  next  higher 
assembly. 


CHANGE  IMPLEMENTATION  PLANNING  SLIDE  10 

Once  the  data  is  accumulated,  the  planner  must  review  a  a  number  of  sub¬ 
jects  before  he  can  prepare  an  effective  plan.  These  issues,  and  their 
significance,  differ  widely  from  one  change  to  the  next.  Consolidation 
of  the  data  into  the  most  effective  plan  requires  experience  and  an 
ability  to  "sense"  a  potential  problem  or  omission.  Typical  of  these 
issues  are: 

•  Finalizing  dispositions.  Dispositions  are  considered  to  be  recom¬ 
mendations  by  Engineering  until  after  technical  review,  when  stock 
level  and  cost  considerations  are  evaluated! 

+  Some  changes  must  be  implemented  as  soon  as  possible.  But  does 
that  mean  accepting  cancellation  charges  ?  Paying  a  premium 
for  short  lead  time?  If  it  does  the  decision  must  be  passed 
on  to  the  Buyer.  A  number  of  conditions  influence  how  fast  is 
possible. 

+  When  there  is  no  specific  need  for  urgency,  implementation 
should  be  based  on  cost  effectiveness.  At  times  this  may 
require  changing  dispositions.  For  example:  Engineering  recom¬ 
mended  a  disposition  of  "EXHAUST  STOCK"  on  a  $25. oo  circuit 
board.  The  change  that  they  were  making  eliminated  $75. oo  of 
rework  on  the  existing  assembly.  In  review,  the  disoosition 
of  the  PC3  was  changed  to  "SCRAP".  Engineering  objected 
because  they  were  responsible  for  the  scrap  budget,  but  reason 
prevailed  and  the  cost  effective  solution  was  used. 
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t  Scheduling  testing  and  validation.  We  assume  that  Engineering  has 
modeled  sensitive  changes  and  tested  them  sufficiently  to  assure 
that  they  work  adequately.  3ut  have  they?  Will  Manufacturing  need 
to  validate  changes  to  the  process  or  to  new  or  revised  equipment? 
These  questions  must  be  considered  and,  when  necessary,  provision 
for  test  or  validation  must  be  included  in  the  plan. 

•  The  potential  impact  of  changes  in  part  usage  must  be  considered. 

+  When  requirements  for  a  part  are  suddenly  doubled  or  tripled, 
inventory  that  was  planned  for  three  months  will  be  exhausted 
in  a  month  or  six  weeks.  If  this  is  less  than  the  procurement 
lead  time,  a  shortage  may  result  if  implemented  too  soon. 

+  When  requirements  for  a  part  are  reduced  to  one  half  or  one 
third,  inventory  for  three  months  will  extend  to  six  or  nine 
months.  When  the  price  of  money  is  high,  this  represents  an 
expense.  Not  usually  a  serious  problem,  but  in  the  extreme  it 
can  represent  a  major  avoidable  expense. 

+  When  a  part  is  needed  to  update  units  in  the  field  it  can 
cause  a  significant  surge  in  production.  For  example: 

If  the  new  part  replaces  one  that  was  built  at  the  rate  of 
100  a  month,  and  10,000  units  in  the  field  need  retrofitt¬ 
ing,  and  10,000  units  in  the  field  need  retrofitting  within 
the  next  year,  requirements  suddenly  jump  from  100  to  1100 
per  month.  By  itself,  this  may  not  be  a  serious  problem, 
but  10  or  15  changes  in  process  at  one  time  with  this 
impact  can  overload  the  plant  capacity. 

•  Compatibility  of  changes.  Engineering  usually  bases  changes  on  the 
assumption  that  the  previous  changes  have  been  implemented.  Often 
the  functional  ties  between  a  new  change  and  earlier  ones  is  not 
known.  This  is  not  a  problem  if  changes  are  implemented  in  the  same 
sequence,  but  this  cannot  always  be  done.  While  one  change  may  take 
months  to  implement,  the  next  one  may  be  implemented  immedi atly . 

+  If  the  changes  are  unrelated  there  is  no  problem. 

+  When  they  are  functionally  related,  but  it  is  not  realized, 
implementation  of  the  new  change  may  stop  production  or  cause 
any  number  of  problems. 

+  If  their  technical  relationship  is  known,  an  answer  can 
usually  be  worked  out.  Even  when  the  relationship  is  known, 
the  answer  may  be  difficult.  For  example, 

Implementing  a  new  circuit  board  including  a  custom  IC  took 
11  months  because  of  IC  lead  time.  About  a  month  after  the 
new  design  was  released,  a  major  functional  problem  was 
traced  to  the  old  design.  Its  resolution  could  not  wait. 

Correcting  the  old  design  required  a  revision  to  change  the 
new  board  back  to  the  old  one,  and  then  correct  the  old 
board.  A  subsequent  change  was  then  needed  to  reinstate 
the  new  design. 
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*  Standard  Cost  is  the  normal  basis  for  cost  comparisons.  This  is 
usually  fine,  but  it  can  be  misleading.  When  standard  costs  are 
not  up-to-date,  the  cost  of  a  new  design  can  be  higher  than  stan¬ 
dard  when,  in  fact,  the  new  part  cost  less  than  the  current  price 
of  the  old  design.  This  makes  a  cost  reduction  look  like  an 
increase. 

•  The  change  implementation  is  usually  based  on  one  of  three  events: 

+  Leadtime  to  buy  parts,  or  time  required  to  change  the  process. 

+  The  time  it  takes  to  use  up  existing  stock. 

+  Implementation  of  a  constraining  change. 

•  When  the  production  schedule  changes,  the  rate  at  which  parts  are 
used  also  changes;  if  implementation  timing  is  based  on  using  or 
reworking  all  existing  stock,  the  implementation  schedule  changes. 
It  also  changes  if  production  does  not  meet  the  schedule. 

To  effectively  resolve  these  issues,  a  planner  must  have: 

•  A  general  understanding  of  the  organization,  equipment,  processes, 
and  documents  associated  with  Production,  Test  and  Inspection. 

•  The  ability  to  sense  when  planning  data  is  missing,  incomplete  or 
erroneous,  be  able  to  correct  it,  or  obtain  what  is  needed. 

•  The  background  or  intuition  needed  to  know  when  and  where  to  apply 
special  analysis,  and  an  understanding  of  when  it  is  HOT  needed. 

•  Background  in  the  principles  and  applications  of  production  control 


TRACKING  SYSTEMS 

REQUIREMENTS  TO  MANAGE  THE  PLAN:  SLIDE  11 

With  a  plan  you  have  a  baseline,  but  monitoring  is  needed  to  manage  it. 
The  better  the  planning  and  the  more  stable  the  environment,  the  fewer 
exceptions.  But  no  mater  what,  problems  arise  and  changes  are  required. 
The  key  is  to  identify  problems  as  soon  as  possible! 

Actual  performance  must  be  tracked  in  order  to  confirm  whether  or  not 
it  is  on  schedule. 

Personnel  must  be  kept  informed  of  any  change  to  their  schedule  commit¬ 
ments!  In  order  to  manage,  each  supervising  manager  must  know  what 
commitments  his  people  have  to  meet.  Higher  levels  of  management  must 
have  the  information  needed  to  measure  the  performance  of  their 
subordinates.  They  must  also  have  exception  data  that  identifies 
problems  that  may  require  action. 

Many  of  these  problems  are  like  cancer.  They  can  easily  be  cured  if 
they  are  found  early  enough,  but  the  longer  the  delay,  the  more 
difficult  and  less  likely  is  a  successful  cure.  We  cannot  afford  to 
wait  until  the  day  before  implementation  to  discover  that  a  holding 
fixture  has  not  been  delivered,  or  the  Process  Instructions  arn't  ready. 
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TRACKING  AND  REPORTING  SYSTEM 


SLIDE  12 


Keeping  track  of  between  8  and  100  events  for  each  of  40  to  100  Changes 
Requires  a  of  these  requirements  is  accomplished  with  a  tracking  system 
that  can  prepare  relevant  reports  for  each  participant  and  his  manager. 

The  system  should  include  comparitively  minor  events.  A  Milestone,  such 
as  TOOLING  AVAILABLE  is  not  good  enough.  If  the  tool  is  not  available 
when  needed,  it  is  usualy  too  late  to  do  anything  about  it.  Inch  Pebbles 
such  as  "Tooling  Data  to  Designer",  "Design  Complete",  "Procurement 
Complete"  "Parts  Received",  and  "Tool  Validated"  are  needed. 

Until  the  last  decade,  gathering  all  of  this  data  has  usually  been  too 
difficult  to  be  beneficial.  However,  by  gathering  data  and  capturing 
transactions  from  other  computer  systems,  and  providing  data  to  those 
systems,  most  of  the  data  are  nearly  free. 

If  the  system  is  on-line  it  can  also  provide  the  service  of  informing 
individuals  of  due  dates  for  their  change  related  activities,  and  the 
status  of  other  activity  that  constrains  them. 

By  linking  the  Tracking  system  to  status  systems  for  Manufacturing  and 
Quality  Control  stations,  tools  and  equipment,  and  Process  Documents 
it  is  possible  to  identify  the  complete  impact  of  a  Proposed  Change. 

CHARACTERISTICS  OF  A  CHANGE  TRACKING  SYSTEM:  SLIDE  13 

To  accomplish  this,  a  system  would  have  to  be  able  to  handle  a  large 
number  of  small  unrelated  and  related  projects,  with  durations  ranging 
between  one  week  and  perhaps  a  year.  It  would  require  a  significant 
number  of  flags  and  specialized  data  in  each  record  for  the  purpose  of 
preparing  reports  and  selecting  specific  records  on  request.  It  should 
use  well  formatted  screens  for  inputting  data  and  requesting  data,  pre¬ 
ferably  menu  driven.  Ordering  of  routine  reports  should  require  simple 
commands  and  special  reports  must  be  easily  formatted  and  ordered. 

Management  reports  should  be  effectively  formatted,  more  on  that  later. 

DATA  REQUIREMENTS:  SLIDE  14 

Each  change  record  should  include: 

t  A  Change  Header  with  the  change  number,  a  basic  description  of  the 
change,  and  the  flags  and  coding  needed  for  inquiry  and  reporting. 

•  A  schedule  of  events  that  relate  to  the  change  as  a  whole. 

•  A  part/docuent  record  for  each  part  or  document  included  within  the 
change.  This  record  would  identify  all  that  was  needed  about  each 
part,  and  its  individual  implementation  schedule. 

•  A  tool /equipment  record  for  each  unit  of  equipment  affected.  This 
record  would  identify  all  that  was  needed  about  each  piece  of 
tooling  or  equipment  required  or  revised  to  support  the  change 
including  its  individual  schedule. 
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OTHER  SYSTEMS  RELATED  TO  CHANGE  TRACKING  SYSTEM: 


SLIDE  15 


A  Change  Tracking  and  Reporting  System  interrelates  a  broad  range  of 
otherwise  independant  activities  with  little  cross  coordination.  The 
data  needed  usually  exists  in  a  number  of  different  systems,  some  may  be 
computerized  and  some  not.  If  a  lot  of  the  data  has  to  be  manually 
gathered  and  posted,  much  of  the  benefit  is  lost;  even  more  is  lost  if 
reports  have  to  be  manually  prepared. 

By  interrelating  with  other  systems  most  of  the  actual  tracking  can  be 
done  automatically,  reducing  the  coordination  and  legwork  needed  to 
maintain  status.  Conceptually  the  system  ties  to  the  Requirements  Plan 
ning  System,  the  Purchase  Order  Control  System,  Floor  Control  System, 
and  any  Status  Systems  for  control  of  Process  Documentation,  Equipment, 
Media,  and  Stations. 

CHANGE  DEFINITION  AND  IDENTIFICATION  DATA:  SLIDE  16 

The  Change  Header  record  should  tell  you  all  you  need  to  know  about  the 
Change.  Besides  number,  description,  and  product,  perhaps  you  need 
contract  number,  customer.  Change  class,  initiator.  Another  item  is 
identification  of  related  changes,  and  possibly  a  constraint  code. 


CHANGE  LEVEL  STATUS,  SORT,  AND  SELECT  DATA  SLIDE  17 

Mixed  in  with  the  descriptive  data  in  the  header  are  codes  and  flags 
to  select  records  for  various  reports.  Fields  to  identify  reason  code, 
logistic  impact,  sensitivity  to  the  production  schedule,  functional 
change,  manuals  affected,  etc. 

These  records  can  also  be  used  to  summarize  cost  data  like  the  estimated 
effect  of  changes  on  product  cost,  or  an  estimate  of  trackable  one  time 
costs  to-date,  or  the  estimated  untrackable  cost. 

Included  also  are  Schedule  Oates  that  apply  to  the  change  as  a  whole. 
When  was  it  received  for  review?  When  Approved  and  released?  When  is 
first  system  test  of  the  changed  configuration  ?  When  does  the  first  one 
snip?  This  does  not  include  dates  associated  with  part  or  tool  changes. 

If  the  change  is  rescheduled  there  should  also  be  an  indication  of  when 
and  why,  perhaps  coded  for  future  sorting  and  analysis. 

PART  IDENTIFICATION  AND  IMPLEMENTATION  DATA:  SLIDE  18 

Each  part  or  document  in  the  change  will  have  its  own  record,  similar  in 
concept  to  the  Change  Header  except  it  contains  part  related  data.  Such 
as.  Part  or  Document  number,  Description,  Disposition,  Cross  reference 
between  superseded  superseding  oart  numbers,  make  or  buy  code,  etc. 

This  record  will  identify  the  ME,  TE,  QE,  etc.  involved  with  the  changes 
to  the  part.  This  identification  can  be  used  to  summarize  listings  for 
each  department  manager.  If  the  record  also  includes  manhour  estimates 
they  can  summarize  the  Change  action  workload  for  each  department. 
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Schedule  data  for  parts  include  such  events  as  PO  Issued,  Parts  on  Dock, 
Kits  Issued  to  Assembly,  Inspection  Instructions  Available,  Process 
Instructions  Available,  Parts  into  Stores,  etc. 

If  the  use  of  a  part  is  sufficiently  increased  by  a  change  to  make  it 
the  pacing  item  for  implementation  or  to  require  expedited  procurement, 
a  tracking  record  is  required  even  though  the  part  was  not  revised. 

EQUIPMENT  IDENTIFICATION  AND  IMPLEMENTATION  DATA:  SLIDE  19 

Although  most  changes  do  not  involve  revision  or  acquisition  of  tools, 
when  they  are  involved  they  are  often  on  the  critical  path.  One  record 
is  required  for  each  unit  of  equipment  affected  by  a  proposed  change. 

The  data  required  is  conceptually  like  that  needed  for  parts. 

MANUAL  TEST  SYSTEM:  SLIDE  2C 

In  order  to  prove  the  concept  of  a  Change  Tracking  System  that  goes  to 
the  detail  I  am  describing,  I  established  a  manual  system.  This  system 
works  fairly  well  for  tracking  and  proved  the  validity  of  the  concept. 

It  improves  coordination  between  Production  Control,  the  manufacturing 
flcc.r.  Manufacturing  Engineering,  and  Quality  Assurance.  However  this 
system  does  not  lend  itself  to  efficient  preparation  of  some  of  the 
neeeded  management  reports. 

A  while  ago  I  mentioned  not  forgetting  old  technology,  here  is  an 
example.  There  is  a  week  ending  calander  on  the  top  edge  of  the  cards. 
Colored  clips  identify  weeks  that  have  a  tracking  event,  colors  identi¬ 
fied  material  events,  production  control /purchasing  events,  and  engin¬ 
eering  events.  3y  looking  down  on  a  file  of  these  cards,  a  status  clerk 
could  identify  what  is  scheduled  for  this  week,  and  what  is  past  due. 

TRACKING  REPORTS:  SLIDE  21 

A  computerized  tracking  system  can  provide  the  following  reports: 

To  keep  personnel  informed  of  change  status,  a  report  is  sent  to  each 
department  involved  with  Change  Implementation.  This  report  identifies 
the  status  of  constraining  activities  and  activities  within  the  depart¬ 
ment.  The  report  provides  status  of  Changes  in  Change  number  sequence, 
it  also  has  cross  reference  lists  in  start  data  and  due  date  sequence. 
These  lists  are  summari zed  for  each  Engineer  and  for  the  Department. 

The  supervisory  manager  of  each  department  gets  a  list  of  changes  involv¬ 
ing  the  department  in  due  date  sequence,  worst  past  due  first.  There  is 
also  a  statistical  report  of  the  activity  and  performance  of  the  depart¬ 
ment  . 


Higher  level  managers  get  a  statistical  summary  of  their  organization's 
activity  and  performance,  a  list  of  activities  that  are  more  than  a 
specified  number  of  days  past  due,  and  a  copy  of  the  report  for  each 
subordinate.  Where  there  are  several  levels  of  higher  management,  the 
threshold  for  listing  past  due  activities  is  progressively  higher. 
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PHILOSOPHY  OF  MANAGEMENT  REPORTING: 


SLIDE  22 


At  times  it  seems  that  data  managers  pride  themselves  with  printing 
paper,--  in  vast  quantities.  More  often  than  not  I  have  run  into 
so  called  reports  that  are  little  more  than  a  file  dump.  I  have  often 
been  given  a  three,  --  four,  --  five  inch  thick  printout  to  analyze  and 
use  to  make  some  conclusions.  Most  managers,  most  employees  do  not  have 
time.  It  is  surprising  how  often  the  ability  of  a  computer  to  select, 
sort  and  analyze  data  is  overlooked.  Half  of  the  value  of  the  system 
I've  been  discussing  is  in  maintaining  status,  THE  OTHER  HALF  IS  PROVID¬ 
ING  DATA  TO  MANAGEMENT.  Good  reports  have  the  following  characteristics. 

•  The  first  sheet  must  inform  the  manager  of  activity  and  potential 
problems.  --ON  ONE  SHEET!  If  possible,  it  should  also  list  the 
most  significant  problems  or  activities  that  are  most  past  due. 

•  Behind  the  first  sheet  is  backup  data  such  as  the  summary  reports 
for  subordinates,  and  more  detailed  listings  of  SELECTED  data. 

•  Limit  listings  to  relevant  data  AVOID  USING  FILE  DUMPS  AS  REPORTS 
UNLESS  SPECIFICALLY  REQUIRED. 

SUMMARY 

Assuming  that  you  had  been  experiencing  these  problems  in  a  similar 
environment,  and  you  have  accepted  and  implemented  my  suggestions: 

•  Your  personnel  are  trained,  qualified,  and  motivated  to  make  the 
system  work. 

•  Your  procedures  are  well  documented,  clearly  written,  2.  under¬ 
stood  by  everyone  involved. 

t  Your  planning  is  based  on  coordination  with  all  potentially 
affected  activities,  and  sound  business  judgement. 

•  Your  operating  systems  provide  all  of  the  information  needed  to 

+  Plan  implementation  of  changes 
+  Inform  all  participants  of  their  obligations 
+  Track  the  Status  of  all  related  activities 
+  Identify  slipping  schedules 

+  Reschedule,  redirect  resources,  or  initiate  other  form  of 
corrective  action 
+  Keep  management  informed 

•  Your  management  is  informed  and  making  sound  decisions. 

•  Your  computer  systems  effectively  exchange  data,  maintain  status 
and  generate  effective  reports. 

•  Most  of  your  changes  are  smoothly  implemented,  when  problems  are 
discovered  they  are  eficiently  resolved. 

Will  you  have  cured  all  of  the  problems?  Not  quite,  the  problems  will 
still  arise  (but  not  as  often  as  before).  But  now,  you  will  identify 
them  early  and  resolve  them  efficiently. 
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MANAGING  CHANGE  IMPLEMENTATION 
(Control  of  problems  after  change  release) 


by 

John  Nast 
NAST  &  Associates 
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CATEGORIES  OF  STABILITY 


•  Inherently  Stable 

•  Design  Sensitive 

•  Process  Sensitive 

•  Installation/ Application  Sensitive 

•  Operation/Maintenance  Sensitive 


SYMPTOMS 

SYMPTOM/DEFICIENCY 
Poor  schedule  coordination  (if  any) 

Poor  material/production  control 
Inability  to  identify  problems  until  too  late 
Poor  coordination  during  implementation 

Insufficient  testing  of  changes 
(Procedures  were  in  place  but  not  followed) 

Lack  of  information  available  to  Planner 
Lack  of  system  knowledge  by  personnel 
Lack  of  motivation  of  personnel 
Ineffective  allocation  of  resources 
Undefined  responsibilities  (and  objectives) 
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CAUSE 

SYSTEM* 

TRG  &  MGMT 

SYSTEM* 

SYSTEM* 

PEOPLE  &  MGMT 

SYSTEM* 
TRAINING 
TRG  &  MGMT 
SYST  &  MGMT* 
SYST  &  MGMT* 
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IMPLEMENTATION  PROBLEMS 


The  following  problems  were  addressed: 

•  Scheduling 

•  Unexpected  Delays 

•  Requirements  Exceed  Capacity 

•  Unanticipated  Scrap/Surplus  ' 

•  Unproven  Design  Changes 

•  Implementation  Plans  vs.  Production  Schedule 

•  Inadequate  Process  Controls 

•  Related  Changes  Not  In  Phase 

•  Correct  Change  Level  Not  Known 

•  Unacceptable  Spares  and  Retrofit  Deliveries 


REQUIREMENTS  FOR  MANAGING  IMPLEMENTATION 

•  People 

•  Planning 

•  Status  Tracking 

•  Reporting 

•  Management 
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PLANNING  CONSIDERATIONS 

•  EFFECTIVE  DISPOSITION  FROM  CORPORATE  &  CUSTOMER 
PERSPECTIVE 

—  Implement  as  quickly  as  possible 
—  Implement  with  most  cost  effective  schedule 

•  DESIGN  TESTING  AND  PROCESS  VALIDATION 

•  POTENTIAL  IMPACT  OF  CHANGES  IN  PART  USAGE 

—  Increased  usage  =  Potential  shortage 
—  Reduced  usage  =  Potential  surplus 
—  Surges  from  field  requirements 

•  COMPATABIUTY  OF  CHANGE  SEQUENCE 

—  Problems  with  extended  implementation 

•  STANDARD  COSTS  VS.  COST  AFFECT  OF  CHANGE 

•  CHANGES  IN  PRODUCTION  SCHEDULE 

—  Implementation  based  on  production  rate 
—  Implementation  based  on  activities 

•  CONFIRM  SCHEDULE  WHEN  CHANGE  IS  RELEASED 

—  Inform  personnel  of  confirmed  and  revised  schedules 

REQUIREMENTS  TO  MANAGE  THE  PLAN 

•  PERSONNEL  MUST  BE  INFORMED  OF  COMMITTMENTS  AND 
SCHEDULE 

•  MANAGERS  OF  THESE  PERSONNEL  MUST  BE  INFORMED  OF 
COMMITTMENTS  AND  SCHEDULE 

•  PERFORMANCE  TO  PLAN  MUST  BE  VERIFIED 

•  PROBLEMS  MUST  BE  IDENTIFIED  AS  EARLY  AS  POSSIBLE 

•  CORRECTIVE  ACTION  SHOULD  BE  INITIATED  WHEN 
PROBLEMS  ARE  IDENTIFIED 

•  PERSONNEL  AND  MANAGERS  MUST  BE  INFORMED  OF 
CHANGES  TO  PLANS 

•  HIGHER  LEVEL  MANAGERS  MUST  BE  PROVIDED  WITH 

—  PERFORMANCE  STATISTICS  OF  SUBORDINATE  GROUPS 
—  EXCEPTION  REPORTS  OF  MAJOR  PROBLEMS 
-  TREND  DATA 
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TRACKING  SYSTEM 

•  DETAILED  TO  LEVEL  OF  “INCH  PEBBLES” 

•  CAPTURE  DATA  FROM  OTHER  SYSTEMS 

•  IDENTIFY  WHAT  EVENTS  SHOULD  TAKE  PLACE 

•  IDENTIFY  PROBLEMS  AS  EARLY  AS  POSSIBLE 

•  PROVIDE  MANAGEMENT  REPORTS 

•  IDENTIFY  THE  FULL  POTENTIAL  SCOPE  OF  A  PROPOSED 
CHANGE 


CHARACTERISTICS  OF  A  CHANGE  TRACKING  SYSTEM 

•  TRACK  A  LARGE  NUMBER  OF  INDEPENDENT  PROJECTS 

•  DURATION  OF  A  WEEK  TO  A  YEAR 

•  HAVE  FLAGS  TO  SELECT  RECORDS  FOR  SPECIAL  REPORTS 

•  FORMATTED  FOR  THE  CONVENIENCE  OF  THE  STATUS 
CLERK 

•  REPORTS  FORMATTED  FOR  EFFECTIVE  USE  BY  MANAGERS 

•  TIE  INTO  RELATED  SYSTEMS  TO  OBTAIN  DATA  AND 
CAPTURE  TRANSACTIONS 

•  PROVIDE  STATUS  ON  AN  INQUIRY  BASIS 


DATA  REQUIREMENTS 

•  CHANGE  ACTION  DEFINITION  AND  IMPLEMENTATION  DATA 

•  SORT  AND  SELECT  CRITERIA  FOR  REPORTS 

•  PART  IDENTIFICATION  AND  IMPLEMENTATION  DATA 

•  EQUIPMENT  IDENTIFICATION  AND  IMPLEMENTATION  DATA 
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OTHER  SYSTEMS  RELATED  TO  CHANGE 
TRACKING  SYSTEM 

•  PART  MASTER  FILE 

—  Obtain  part  related  data.  Update  part  status  in  PMF. 

•  P.O.  CONTROL  SYSTEM 

—  Obtain  P.O.  number.  Confirm  that  procurement  activities  and  supplier 
committments  conform  to  the  plan. 

•  FLOOR  CONTROL  AND  REQUIRMENTS  PLANNING  SYSTEM 

—  Track  material  movement  and  confirm  that  it  meets  the  plan. 

•  STATION  STATUS  SYSTEM 

—  Obtain  status  of  Equipment,  identify  when  change  is  implemented. 

•  INSTRUCTION/PROCEUURE  STATUS  SYSTEM 

—  T rack  preparation  of  Process  Documents  and  Media 


CHANGE  DEFINITION  AND  IDENTIFICATION  DATA 

•  CHANGE  IDENTIFICATION: 

—  Change  Number,  Description,  Product 

•  ENGRG.  REPSONSIBILITY: 

—  Name  of  Engineer,  Change  Analyst,  etc. 

•  INITIATION: 

—  ECR  Numbver,  Prepared  by,  etc. 

•  RELATED  CHANGES: 

—  Change  Number,  Compatibility  code,  status,  etc. 


G-l  9 


l 


SORT  AND  SELECT  CRITERIA  FOR  REPORTS, 
CHANGE  LEVEL 

•  AREAS  AFFECTED, 

—  Spares,  Retrofit  kits,  CEM  Customers,  etc. 

—  System  test,  Final  Assembly,  Shipping,  etc. 

•  COST  DATA; 

—  Change  in  unit  cost,  one  time  cost,  etc. 

•  PLANNING  DATA: 

—  RPS  Run,  Schedule  sensitivity,  etc. 

•  SCHEDULE  DATA: 

—  List  of  Change  events  with  SCHEDULE,  RESCHEDULE,  and  ACTUAL  dates 
for  each. 

•  RESCHEDULE  DATA: 

—  Date.  RPS  Run,  Reason  Code,  and  Remarks  to  explain  why  plan  was 
rescheduled. 


PART  IDENTIFICATION  AND  IMPLEMENTATION  DATA 
Multiple  records  per  Change,  one  for  each  part  affected. 

•  PART  DEFINITION 

—  P/N,  Description,  Superseded  P/N,  Disposition,  Type  Code 

•  SPECIAL  FLAGS 

—  Spare  part/Retrofit  Code,  Mfg.  Dept/Make/Buy  Code 

.  IDENTIFICATION 

—  ME  QE  Buyer,  PCA,  etc. 

•  SCHEDULE  DATA 

—  Part  events,  with  SCHEDULE  RESCHEDULE  and  ACTUAL  dates  for  each. 

•  MANHOUR  ESTIMATES 

—  Estimates  for  ME  QE  TE  labor  and  estimated  rework  per  part. 

•  DATA  AFFECTED 

—  List  of  Instructions,  Procedures,  Programs,  and  Equipment  to  be  revised 
to  implement  the  change  to  the  part. 
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EQUIPMENT  IDENTIFICATION  AND  IMPLEMENTATION 
DATA 


Multiple  records  per  Change,  one  for  each  unit  of 
equipment  affected. 

•  DEFINITION 

—  Equipment  ID,  Description,  Action,  Type  Code 

•  SPECIAL  FLAGS 

—  Using  Dept,  Operation,  Make/Buy  Code 

•  IDENTIFICATION 

—  Requestor,  Designer,  Buyer,  PCA 

•  SCHEDULE  DATA 

—  Events,  with  SCHEDULE,  RESCHEDULE,  and  ACTUAL  dates  for  each. 

•  DATA  AFFECTED 

—  List  of  Docments  to  be  revised  to  implement  the  change  to  the  part. 


MANUAL  TEST  SYSTEM 
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TRACKING  REPORTS 


•  List  the  Change  related  committments  for  each  participating 
function  so  that  they  can  maintain  their  status. 

•  Summary  report  to  each  supervisory  manager  of  a  participating 
function. 

—  Statistical  summary  of  actiwity/performanca 
—  Trend  analysis 

—  List  of  late  activities  in  order  of  amount  past  due 


•  Summary  reports  to  higher  level  management 

—  Statistical  summary  of  activity/performance,  backed  up  with  copies  of  same 
report  summarized  for  each  subordinated. 

—  Trend  analysis 

—  List  activities  over  XX  days  past  due 


PHILOSOPHY  OF  MANAGEMENT  REPORTING 

•  FIRST  PAGE  MUST  TELL  THE  STORY 

•  BACKUP  SUMMARIES  SHOULD  FOLLOW 

•  EXCEPTION  REPORTING  OF  MOST  SIGNIFICANT  ITEMS 
(In  order  of  significance,  days  past  due,  etc.) 

•  LIMIT  REFERENCE  LISTINGS  TO  RELEVANT  RECORDS 

AVOID  USING  FILE  DUMPS  AS  REPORTS  UNLESS  SPECIFICALLY 
REQUIRED. 
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IN  CONCLUSION 


I  HAVE  PROBABLY  NOT  ANSWERED  ALL 
OF  YOUR  QUESTIONS 

THOSE  I  HAVE  ANSWERED  PROBABLY  HAVE 
ONLY  INTRODUCED  NEW  QUESTIONS 

YOU  ARE  PROBABLY  LEAVING  THIS  SESSION  AS 
CONFUSED  AS  YOU  WERE  WHEN  YOU  ARRIVED 

IDO  HOPE  THAT  YOU  ARE  CONFUSED  AT  A 
HIGHER  LEVEL  ABOUT  MORE  IMPORTANT  THINGS. 
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COMPUTERIZED  MANAGEMENT 
OF 

ENGINEERING  DOCUMENTATION 


Presented  by 
Thomas  Henderson 
Business  Systems  Specialist 
Technical  Affairs  Office 

Ford  Aerospace  &  Communications  Corporation 

Palo  Alto,  CA 


CaSO  *ocd  Aorospoco  A 

Communications  Corporation 


OR 

WHAT  HAPPENS  TO  DESIGN  AFTER 
RELEASE  FOR  PRODUCTION 
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Management  of  engineering  documentation  does  not  stop  when  engineering,  drafting,  and 
configuration  control  board  are  done. 


We  still  have  to  build  the  product  and  manage  changes.  This  presentation  shows  the 
computerized  approach  developed  by  Ford  Aerospace  &  Communications  Corporation, 
WDL  Division,  to  help  manage  these  processes. 


we  want  you  to  hear  about  it! 


The  Product  Support  Systems  serve  three  major  functions:  engineering  information, 
material  planning,  and  production  control. 


MICROCOPY  RESOLUTION  TEST  CHART 

NAItliNAl  HURIAU  Of  STANDARDS  |%<A 


The  FACC  WDL  Product  Support  Systems  are  a  modular  network  of  eight  standalone  systems 
integrated  into  a  common  network. 


Some  people  interface  with  just  one  of  the  modules  and  some  use  many.  As  we  will  see 
though  the  separate  elements  support  one  another  so  that  even  those  who  interface  with 
only  one  element  are  utilizing  data  provided  by  two  or  more  of  the  elements.  The 
systems  share  data  and  this  sometimes  is  not  obvious  to  the  user. 


This  network  uses  proven  tools  with  hardware  presently  available  or  obtainable. 


Let’s  go  over  the  eight  elements  and  see  what  they  do  to  aid  in  our  success. 


It  all  begins  with  the  design  -  manually-created  or  CAD  designs  are  generated.  FACC 
WDL  currently  uses  three  CAD  systems.  Plans  are  underway  to  tie  the  CAD  part  libraries 
to  the  engineering  information  systems.  Meanwhile,  however,  the  Master  Part  Catalog 
module  is  used  in  both  the  manual  and  computerized  drafting  systems  to  obtain  standard 
ized  part  numbers  and  data  -  currently  over  a  quarter  million  part  records  are  on  file. 


MPC 
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fire -scan  master  part  catalog  scan 


TIME;  031083  HZ* 


PART 

number 

548429- 1 
540429-1 
548429-1 
548429-1 
548429-1 
548429-1 
548430-1 
546430' 
548430- 
548430- 
548430- 
548430- 
548431- 
548432- 
548433- 
548434- 
540435- 
548434- 
548437- 


FSCN 

11530 

11530 

11530 

11530 

11530 

11530 

11530 

11530 

11530 

11530 

11531 
11530 
11530 
11530 
11530 
11530 
11530 
11530 
11530 
11530 
11530 

CONTINUE  OR 


OOCUNEN  r 

NUMBER 

340429 

546429 

548429 

548429 

548429 

548429 

548430 

548430 

548430 

548430 

548430 

548430 

548431 

548448 

548433 

548434 

548435 

546440 

548440 

540430 

540440 

enter  NEW 


DESCRIPTION 

BASE. 

CLAMP , 

HOLDER , ADAPTER , 
SUPPORT ,  NG, 

MOUNT .HOLDER  , 
BRACE. MOUNT, 
FIXTURE  ASST, 
BASE. 

CLAMP . 

HOLDER, ADAPTER, 
SUPPORT, WG, 
LOCATCR.MTG  eye, 
EQUALIZER  ASSY, 
EQUALIZER  ASSY, 
EQUALIZER  ASSY, 
EQUALIZER  ASSY, 
EQUALIZER  ASSY, 
EQUALIZER  ASSY, 
EQUALIZER  ASSY, 
EQUALIZER  ASSY, 
EQUALIZER  ASSY. 
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Once  the  CAD  plot  or  manual  design  drawing  and  parts  lists  are  ready  for  release,  they 
are  entered  into  the  engineering  information  system  (ENG).  The  engineering  information 
system  consists  of  three  files  -  Product  Structure,  Document  Status,  and  Document 
Distribution. 


In  the  product  structure 

•  Parts  List  Worksheet  input  by  the  Engineering  Release  Unit. 

•  Treeing  is  performed  by  the  system 

•  Over  25,000  assemblies  on  file  with  1  million  line  items 

•  Eventually  will  be  replaced  by  CAE  inputs 

•  On-line  inquiries  show:  single-level  part  lists,  where-used  information 


A, 

cv  & 

NS*. 


ENGINEERING  SERVICE  CENTER 


ENG 


A, 


4 


H— 7 


J 


Document  Status 


•  On-line  status  of  over  100,000  released  documents  (includes  specifications, 
statements  of  work,  drawings,  parts  lists,  and  engineering  change  orders). 

•  Tracking  through  release  and  repro  cycle 

•  Assures  latest  status,  including  all  outstanding  ECOs 


Document  Distribution 

•  On-line  record  of  ail  names,  phone  extensions,  and  mail  stops  of  everyone 
who  needs  copies  of  released  documents 

-  Document  Distribution  96  people,  average  300  documents  each 
Project  Distribution  326  project  codes,  average  10  people  each 
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Let's  return  for  a  few  moments  to  the  Master  Part  Catalog  -  in  addition  to  helping  the 
designer/draftsman,  the  catalog  provides  for  consistent  identification  of  parts  across 
alt  systems,  thus  improving  the  integrity  and  competency  of  system  interfaces. 


Key  outputs  include: 


Indentured  parts  lists 
Consolidated  where-used  reports 
Program  part  summary  lists 
Delta  part  requirement  lists 


MRG 
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MRG  -  This  system  is  now  being  modified  to  not  only  keep  track  of  all  program  hardware 
requirements  but  also  to  track  those  requirements  by  performing  organization. 


We’ve  identified  the  material  requirements  ...  now  what,  coach? 


The  Acquisition  System  is  an  efficient 
those  needs  can  be  met  from  existing 


tool  used  to  record  material  needs,  ar,d  see  if 
stocks  and  generate  the  appropriate  paperwork  to 


acquire  the  needed  material. 


Inputs  Entered 


En  masse  from  MRG  or 
Individually  via  on-line  transactions 


We've  generated  the  acquisition  documents.  Now  additional  acquisition  data  is  loaded 
to  the  Purchased  Material  Status  System  (PMS). 

PMS  tracks  and  provides  full  status  of  goods  and  services 

•  When  the  Supply  Requisition  hit  Purchasing 

•  Assignment  of  Buyer 

•  Placement  of  order 

•  Receipt  of  material 

•  Inspection  of  material 

•  Delivery  of  material 


PMS 


Inputs 

•  Automatically  from  ACQ  or. 

•  Each  manual  SR  submitted  is  entered  on-line 

•  Promised  delivery  dates  (from  Buyer) 

•  Actual  receipt  dates  (from  Receiving) 

•  Inspection  results  (from  Receiving  Inspection) 


PMS 
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Automatic  inputs  include  document  revision  status  from  ENG,  SR  details  from  ACQ  and  delivery 
information  from  the  Inventory  Control  System. 


PMS  is  controlled  by  the  Materiel  Office  and  provides  the  critical  part  delivery  data 
necessary  for  production  control. 


PMS  provides  visibility  of  purchased  parts  from  the  time  an  SR  is  received  in  purchasing 
until  the  item  is  received  and  inspected. 


The  Inventory  Control  Systems  (ICS)  maintains  on-hand  balances  in  stores 


Kit  Status  System  (KSS)  simulates  actual  kitting  to  determine  parts  availability  by  kit. 


The  inputs  are  project  kit  schedules,  and  automatically,  single  level  kit  structure  from 

"*G‘*nd  Purchase  0rder  Status  from  P MS.  Other  inputs  are  Shop  Order  Status  from  MFC 
and  Storeroom  on-hand  status  from  ICS. 


PROJECT  KIT  SCHEDULES 


STOREROOM  ON-HAND  STATUS  FROM  ICS 


SHOP  ORDER  STATUS  FROM  MFG 

* 

*  KSS 

%  ■ 

PURCHASE  ORDER  FROM  PMS 


4 

SINGLE  LEVEL  KIT  STRUCTURE  FROM  MFG 
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KSS  is  controlled  by  the  using  department.  Its  key  outputs  are  paper  kit  status  that 
simulates  actual  kitting,  shortage  reports  used  for  expediting,  and  kit  lists. 


KSS  takes  the  requirements  from  MRG  and  simulates  filling  these  requirements.  It  obtains 
purchased  part  status  from  PMS  and  on-hand  inventory  from  ICS  and  WIP  from  MFG.  This 
simulation  enables  managers  to  ascertain  when  parts  are  needed  -  without  physically 
“kitting"  the  material. 


The  eighth  and  final  module,  Manufacturing  Scheduling/Planning  (MFG),  helps  schedule  the 
Shop  Floor,  tracks  work  in  process,  prepares  routings  and  shop  orders  and  plans  capacity. 


Capacities 

Required  completion  dates 
Touch  labor  completed 


/ 


MFG 


PART  DESCRIPTION  DATA 


SUPPLIER  DELIVERY  INFORMATION 


Remember  that  these  tools  are  working  here  now  at  WDL  with  a  proven  training  program. 

Each  module  provides  valuable  data  but  used  together  they  form  a  powerful  tool  for 
managing  program  schedules. 


Through  all  steps  from  design  to  shipment,  computer  tools  are  used  to  manage  the 
engineering  documentation  and  changes  to  assure  that  material  is  not  bought  nor 
parts  built  to  obsolete  designs. 


*Ktj  Aaroaeaca  * 

Comm  Ulrica  tfona  Corporation 
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OSD  DATA  INITIATIVES 
by 

Col.  Walker  A.  Larimer,  USAF 
Director,  Defense  Material 
Specifications  and  Standards  Office 
Falls  Church,  Virginia 


i 


mtmilSh' 


•  REDUCE  DATA  REQUIREMENTS  AND  COSTS 

••  Identify  cost  Drivers 
m  Scrub  Down  Requirements 
••  Implement  Recommendations 

•  OSD  PERSPECTIVE  OF  THE  OOD/JCP  TECHNICAL  INFORMATION  COMMITTEE 

i<  DoD  Teamwork  i  Cooperation  Critical  to  Success. 

••  Tri-Service  Review  of  Plans 
Progress,  and  Future  Systems 

••  Single  Integrated  Plan 

m  Single  Interface  with  JCP 


REQUIREMENTS  AMD  DATA  DRIVERS 


REGULATORY 

PROVISIONS 

FINANCIAL  4 
ADMINISTRATIVE 

ENGINEERING  4 
PRODUCTION  TASKS 

04 M  TASKS 

REQUIREMENTS  4 

DATA  SOURCE 

•  STATUTES 

•  DAR 

•  DAR 

•  MISSION  PERF. 

•  OPERATIONAL  MEED 

•  TECHNOLOGY  BASE 

QAM  ENVIRONMENT 

OAM  CHARACTERISTICS 

CONTRIBUTION  TO 
SYSTEM  PERFORMANCE  | 
EFFECTIVENESS 

NONE 

MINIMAL  - 
EARLY  WARNING 

RE  COST/ SCHEDULE 

DEFINES/ESTABLISHES / DETERMINES 

SYSTEM  PERFORMANCE,  OPERATIONAL  AND 
SUPPORT  REQUIREMENTS 

RELATIONSHIP  TO 
WEAPON  SYSTEM 
ACQUISITION  PROGRAM 

INDEPENDENT 

DEPENDENT  ON 

ACQUISITION 

STRATEGY 

UNIQUELY  TAILORED 
TO  EACH  SYSTEM 

DATA  IS  BY  PRODUCT 
OF  TASK 

TRADE  OFF  BETWEEN 
SYSTEM  REQUIREMENTS 
AND  OAM  DOCTRINE 

DATA  IS  BY  PRODUCT 

DATA  UTILIZATION 

COMPLIANCE 

WITH  REGULATORY 
PROVISIONS 

TRACK  COST  4 
SCHEDULE 

i 

VERIFICATION  OF 

COMPLIANCE 

"REPROCUREMENT* 

BASIS  FOR  OPERATION, 
MAINTENANCE  AND 
SUPPORT 

PERCEIVED  COST 
IMPACT  OP  DATA 

HIGH 

MED 

LOW 

LOW-MED 

REMARKS 

SOCIO-ECONOMIC 
INITIATIVES  - 
NON  COD 

CAN  DRIVE 
COMPLIANCE  RATHER 
THAN  TOOL  FOR 
CONTROL 

TASKS/REQUIREMENTS  DRIVE  COSTS 

DATA  IS  "FALL-OUT" 

RECOMMENDATION 

PERIODIC  CGdPL. 

VS  CONTRACT 
,  DRIVEN 

ELIMINATE  EXCESS 
DETAIL 

TAILOR  TASKS  AND  REQUIREMENTS 

TAILOR  DATA  REQUIREMENTS  TO  CORRELATE 
WITH  TASKS /REQUIREMENTS 
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•  LARGE  PRIME  CONTRACTOR  IDENTIFIES  AND  DOCUMENTS  NONESSENTIAL 

REQUIREMENTS  (Completed  April  1983). 

••  Second  Prime  Contractor  Reviews  and  Comments  on  Results. 

•  JOINT  LOGISTICS  COMMANDERS  (JLCs)  REVIEW  REPRESENTATIVE  DOD  CONTRACTS 

AND  PROVIDE  RECOMMENDATIONS  (IN  WORK). 

I  DEFENSE  SYSTEMS  MANAGEMENT  COLLEGE  (DSMC)  CONSOLIDATES  INPUTS  FROM 
CONTRACTORS  AND  JLCs  (In  Work).  PROVIDES  RECOMMENDATIONS  TO 
OUDSRE  (30  June  1983)  FOR  AIP  »\H  CONSIDERATION. 

I  PILOT  TEST  IMPLEMENTATION  OF  DSMC's  RECOMMENDATIONS  BY  ALL  SERVICES. 

ti  Implement  the  best  ideas  (6  to  12). 

ii  Incentives  for  the  contractor  and  govt  program  manager. 

(•  Negotiated  in  the  contract. 
it  Contract  tailored  for  the  environment. 

••  Do-able  in  the  near-term, 
ii  More  hardware  for  less  paper 


PRIME  CONTRACTOR'S  REVIEW 

I  CONTRACTUAL  OBJECTIVES  HAVING  ULGH  COST  IMPACT  ON  MANAGING  AEROSPACE  BUSINESS 

mmn 

’  Socio-Economic. 

••  Evaluation  of  Subcontract  °roposals. 
ii  Inadequate  Early  Spaces  Support. 

••  Contractor  Maintenance  ''S  Organic  Depot, 
ii  Change  Processing, 
ii  Government  Property  Procedures. 

••  Designated  Engineering  i  Manufacturing  Inspection  Reps. 


>REAS  WHERE  POP  CONTRACT  DOCUMENT  RFQMTS  COMPEL  CONTRACTORS  TO  MANAGE  AT  A  LEVEI 


OF  DETAIL  THAT  IS  UNPRODUCTIVE.  (S  RECS. ) 


••  Cost  Management  Reporting. 

••  Schedule  Reporting. 

ii  Program  Management  Reviews  and  Narrative  Reports. 
••  Life  Cycle  Cost/Design  to  Cost. 
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(I!  RECS.i 


it  Source  Selection. 
it  Follow-on  Procurement. 

••  Proposal  Complexity  and  Revisions, 
m  Data  Requirements  (Before  am:  After  Contract  Award). 
••  System  Enhancement  and  Upgrade  Programs. 


ii  Managing  Development  and  Allocation  of  Systems  Requirements. 

-  System  Specification  requirements. 

-  Verification  Requirements. 

-  Technological  Currency  and  Tailoring. 

-  Trend  Toward  'How  To. ' 

-  Specification  Trees. 


ii  Growth  of  Management.  Functional  and  Speciality  Tasks. 


DEFENSE  SYSTFMS  MANAGEMENT  CPI !  EGE  R£YQ 

•  ESTABLISHED  WORKING  GROUP  -  7  PROFESSIONALS. 

ii  Continued  Suppopt  =rom  Military  Departments. 

•  NOW  REVIEWING  PRIME  CONTRACTOR'S  RECOMMENDATIONS. 

•  NOW  REVIEWING  DRAFT  REPORTS  OF  ARMY  AND  NAVY. 

•i  All  Military  Department  Reports 
Due  JLCs  !6  May  1933. 

I  DETERMINE  CAUSES  FOR  PROBLEMS. 

I  REPORT  RECOMMENDATIONS  TO  OUSDRE. 
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9-502  ACQUISITION  OF  TECHNICAL  DATA  AND  COMPUTER  SOFTWARE 


(a)  Technical  data  and  computer  software  is  expensive  to  prepare  in 

THE  REQUIRED  FORM  AND  TO  MAINTAIN  AND  UPDATE.  EvERY  EFFORT,  THEREFORE. 
SHOULD  8E  MADE  TO  AVOID  PLACING  A  REQUIREMENT  UPON  A  CONTRACTOR  TO  PREPARE 
AND  DELIVER  DATA  OR  SOFTWARE  UNLESS  THE  NEED  IS  POSITIVELY  DETERMINED. 


OSD  PERSPECTIVE  GF  THE  OOD/JCP  TECHNICAL  INFORMATION  COMMITS 

•  COD/JCP  CO-CHAIRMEN  PROVIDE  CO-SIGNED  RECOMMENDATIONS  ON  SYSTEM  ACQUISITIONS  TO  JC? . 

Lazorchek  (JC?)  -  JCP  Co-Chairman 
RICHARDSON  (DMSSO)  -  DoD  Co-Chairman 

•  COD  POSITION  FORMULATED  WITHIN  TRI-SERVICE  WORKING  GROUP  ENVIRONMENT  AND 

COORDINATED  WITH  ADUSD(PS)  PRIOR  TRANSMITTAL  TO  JCP. 

•  ALL  MILITARY  DEPARTMENT  PRINCIPALS  MUST  COORDINATE  AND  AGREE  ON  INDIVIDUAL 

SERVICE' REQUESTS  TO  JCP 

-  Does  it  conform  with  established  tri-service  program? 

-  Does  it  satisfy  service  requirement? 

-  Does  it  make  sense? 

-  Do  changes  make  sense"’ 

•  ALL  MILITARY  DEPARTMENT  PRINCIPALS  MUST  PARTICIPATE  IN  JCP-DIRECTED  TRI-SERVICE 

evaluations  of  equipment 

-  Evaluations  scheduled  and  tri-service  principals  notified  by  service 

host. 

I  DMSSO  PRGVIDES  SINGLE  INTERFACE  FOR  DOD  WITH  JCP.  POLICY  DOCUMENTS  Will  SOON  REFLEC" 
THIS  CHANGE,  JC?  WILL  3S  FORMALLY  ADVISED. 
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^ -201  DEFINITIONS.  For  the  purpose  of  this  Fart,  the  following  terms 

HAVE  THE  MEANINGS  SET  FORTH  BELOW: 

(A)  DATA  means  recorded  information,  regardless  of  form  or  characteristic. 

(b)  TECHNICAL  DATA  means  recorded  information,  regardless  of  form  or 
CHARACTERISTIC.  OF  A  SCIENTIFIC  OR  TECHNICAL  NATURE.  IT  MAY,  FOR  EXAMPLE.  DOCUMENT 
RESEARCH.  EXPERIMENTAL.  DEVELOPMENTAL  OR  ENGINEERING  WORK  I  OR  BE  USABLE  OR  USED  TO 
DEFINE  A  DESIGN  OR  PROCESS  OR  TO  PROCURE.  PRODUCE.  SUPPORT.  MAINTAIN.  OR  OPERATE 
MATERIEL.  Th£  DATA  HAY  BE  GRAPHIC  OR  PICTORIAL  DELINEATIONS  IN  MEDIA  SUCH  AS 
DRAWINGS  OR  PHOTOGRAPHS;  TEXT  IN  SPECIFICATIONS  OR  RELATED  PERFORMANCE  OR  DESIGN 

type  documents;  or  computer  printouts.  Examples  of  technical  data  include  research 

ANO  ENGINEERING  DATA.  ENGINEERING  DRAWINGS  AND  ASSOCIATED  LISTS,  SPECIFICATIONS. 
STANDARDS.  PROCESS  SHEETS.  MANUALS.  TECHNICAL  REPORTS.  CATALOG  I  TEH  IDENTIFICATIONS 
AND  RELATED  INFORMATION.  AND  DOCUMENTATION  RELATED  TO  COMPUTER  SOFTWARE. 

Technical  data  does  not  include  computer  software  or  financial,  administrative. 

COST  AND  PRICING.  AND  MANAGEMENT  DATA  OR  OTHER  INFORMATION  INCIDENTAL  TO  CONTRACT 
ADMINISTRATION. 
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COMPETITION 


A  N  D 

COOPERATION 


Captain  Thomas  J,  Burke,  USN 

Commanding  Officer,  Naval  Sea  Systems 
Command  Logistics  Support 
Engineering  Activity 

Officer  in  Charge,  Naval  Electronic 
Systems  Command  Detachment 
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GOOD  MORNING  LADIES  AND  GENTLEMEN.  IT  IS  A  DISTINCT 
PLEASURE  FOR  ME  TO  BE  HERE  AT  THE  25TH  ANNUAL  MEETING  OF  THE 
TECHNICAL  DOCUMENTATION  DIVISION  OF  THE  AMERICAN  DEFENSE 
PREPAREDNESS  ASSOCIATION,  AND  TO  REPRESENT  NAVY  ON  THE  MILITARY 
PANEL.  I  MUST  ADD  THAT  I  ALSO  REPRESENT  THE  CENTRAL  PENNSYLVANIA 
MANAGEMENT  CHAPTER  OF  ADPA  LOCATED  IN  MECHANICSBURG,  PENNSYLVANIA, 
WHERE  I  AM  A  MEMBER  IN  GOOD  STANDING. 

TO  SET  THE  STAGE  FOR  MY  REMARKS  AND  SO  THAT  YOU  WILL  PLACE 
THEM  IN  PROPER  PERSPECTIVE,  I  NEED  TO  TELL  YOU  A  FEW  THINGS 
ABOUT  MYSELF  AND  THE  ACTIVITIES  I  REPRESENT.  ALTHOUGH  I  AM  THE 
"NAVY"  REPRESENTATIVE,  IT  IS  OBVIOUS  THAT  SOME  OF  MY  REMARKS 
WILL  EE  SLANTED  TO  AND  BIASED  BY  MY  PRESENT  POSITIONS.  FIRST, 

I  AM  A  SURFACE  WARFARE  OFFICER  -  A  SHIP  DRIVER.  I  AM  NOT  AN 
ENGINEER  BY  EDUCATION,-  HOWEVER,  I  HAVE  A  STRONG  TECHNICAL 
BACKGROUND  BOTH  BY  TRAINING  AND  SHIPBOARD  EXPERIENCE.  I 
CURRENTLY  HAVE  ASSIGNMENTS  WITH  THREE  SEPARATE  ACTIVITIES  IN 
THE  MECHANICSBURG,  PENNSYLVANIA,  AREA.  MY  PRIMARY  DUTY  IS  AS 
COMMANDING  OFFICER  OF  THE  NAVSEA  LOGISTICS  SUPPORT  ENGINEERING 
ACTIVITY,  A  NAVAL  SEA  SYSTEMS  COMMAND  FIELD  ACTIVITY.  I  HAVE 
AN  ADDITIONAL  DUTY  ASSIGNMENT  AS  OFFICER  IN  CHARGE,  NAVELEX 
DETACHMENT  IN  MECHANICSBURG,  A  NAVAL  ELECTRONICS  SYSTEMS  COMMAND 
FIELD  ACTIVITY.  THESE  ACTIVITIES  ARE  DEEPLY  INVOLVED  IN  THE 
PROVISIONING  PROCESS  FOR  HULL,  MECHANICAL  AND  ELECTRICAL 
EQUIPMENTS,  AS  WELL  AS  SEARCH  RADARS,  SONARS  AMD  TACTICAL 
COMPUTERS  FOR  NAVSEA,  AND  FOR  ALL  NAVELEX  EQUIPMENTS. 
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IN  ADDITION,  BOTH  ACTIVITIES  PROVIDE  ENGINEERING  SERVICES  TO 
NAVY  SHIPS  PARTS  CONTROL  CENTER  (SPCC)  FOR  RESOLUTION  OF 
TECHNICAL  PROBLEMS  RELATED  TO  SPARE  PARTS  REPROCUREMENT.  I 
LIKE  TO  REFER  TO  MY  PEOPLE,  MOST  OF  WHOM  ARE  ENGINEERS,  AS 
INTERPRETERS  BETWEEN  THE  ACQUISITION  MANAGERS  IN  NAVSEA  AND 
NAVELEX  AND  THE  SUPPLY  SYSTEM,  PRINCIPALLY  SPCC  AS  THE  PRIMARY 
INVENTORY  CONTROL  POINT  FOR  SHIPS.  INTERPRETERS  OBVIOUSLY 
SPEAK  AT  LEAST  TWO  LANGUAGES;  THUS,  MY  ENGINEERS,  IN  ADDITION 
TO  BEING  QUALIFIED  IN  THEIR  OWN  LANGUAGE,  ALSO  SPEAK  "SUPPLY", 

A  LANGUAGE  WHICH  IS  FOREIGN  TO  MOST  OF  THOSE  IN  THE  ACQUISITION 
BUSINESS. 

MY  THIRD  POSITION,  ANOTHER  ADDITIONAL  DUTY  ASSIGNMENT,  IS 
AS  ENGINEERING/TECHNICAL  ASSISTANT  TO  THE  COMMANDING  OFFICER  OF 
SPCC,  COMMODORE  ROBERT  B.  ABELE,  SC,  USN. 

MY  APPEARANCE  HERE  TODAY  IS  SOMEWHAT  OF  A  FOLLOW  ON  TO 
YOUR  EXECUTIVE  BOARD  MEETING  HOSTED  BY  THE  CENTRAL  PENNSYLVANIA 
MANAGEMENT  CHAPTER  OF  ADPA  IN  MECHANICSBURG  FROM  27-29  SEPTEMBER 
1932.  AT  THAT  TIME,  MR.  DICK  McFARLAND,  THE  EXECUTIVE  DIRECTOR 
OF  SPCC,  AND  I  HAD  THE  PRIVELEGE  OF  PARTICIPATING  IN  DISCUSSIONS 
WITH  MEMBERS  OF  THE  EXECUTIVE  BOARD.  DURING  THOSE  DISCUSSIONS, 

WE  OPENED  THE  DOOR  TO  SOME  OF  THE  POINTS  I  WISH  TO  LEAVE  WITH  YOU. 
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IN  THE  SHIPS'  WORLD  WE  HAVE  TWO  GENERAL  CATEGORIES  OF 
EQUIPMENTS  -  GOVERNMENT  FURNISHED  AND  CONTRACTOR  FURNISHED. 

MOST  OF  YOU  ARE  MORE  CLOSELY  ASSOCIATED  WITH  THE  GOVERNMENT 
FURNISHED  EQUIPMENTS  WHICH  ARE  MOST  OFTEN  INTRODUCED  TO  THE 
FLEET  THROUGH  THE  RSD  CYCLE  WITH  THE  NAVY  FREQUENTLY 
PARTICIPATING  IN  OR  PROVIDING  FUNDING  FOR  THE  DESIGN  PROCESS. 

IN  MANY  OF  THESE  CASES,  THE  NAVY  ACTUALLY  ACQUIRES  A  MAJORITY 
OF  THE  TECHNICAL  DATA  OR  THE  RIGHTS  TO  THAT  DATA.  MOST  OF 
THESE  EQUIPMENTS  FALL  INTO  THE  ELECTRONIC  OR  ORDNANCE  CATEGORIES. 
HOWEVER,  THERE  ARE  SOME  HULL,  MECHANICAL  AND  ELECTRICAL  (HMSE) 
EQUIPMENTS  SUCH  AS  PROPULSION  GAS  TURBINES,  WHICH  ALSO  FALL 
INTO  THIS  GOVERNMENT  FURNISHED  CATEGORY.  CONTRACTOR  FURNISHED 
EQUIPMENT  IS  SUPPLIED  BY  THE  SHIPBUILDER  TO  MEET  PERFORMANCE 
SPECIFICATIONS  CALLED  OUT  IN  THE  SHIPBUILDING  CONTRACT.  THESE 
ARE  USUALLY  OFF-THE-SHELF,  COMMERCIAL,  MARINE  APPLICABLE  HM&E 
EQUIPMENTS;  BUT  NOT  ALWAYS.  IN  RECENT  YEARS,  WE  HAVE  SEEN  MORE 
SMALL  ELECTRONIC  ITEMS,  INTERCONNECTING  DEVICES,  REMOTE  CONTROL 
UNITS  AND  OTHER  PERFORMANCE  SPECIFICATION  ITEMS  BEING  PROVIDED 
BY  THE  SHIPBUILDER.  THE  MAIN  POINT  HERE  IS  THAT  ALMOST  ALL 
CONTRACTOR  FURNISHED  EQUIPMENT  IS  PROCURED  TO  PERFORMANCE 
SPECIFICATIONS  WITH  LITTLE  TO  NO  STANDARDIZATION.  SINCE  NAVY 
GENERALLY  HAD  NO  PART  IN  THE  DEVELOPMENT  OF  THESE  EQUIPMENTS, 

AND  DOES  NOT  NORMALLY  CONTROL  THE  EQUIPMENT  DESIGN,  THE  GOVERNMENT 
HAS  NO  RIGHTS  TO  TECHNICAL  DATA  AND  VERY  FREQUENTLY  THE  EQUIPMENT 
MANUFACTURER  REFUSES  TO  SELL  SUCH  DATA  TO  NAVY. 
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ALL  THIS  PREAMBLE  WAS  MEANT  TO  LEAD  INTO  MY  TWO  PRINCIPAL 
THEMES  --  COMPETITION  AND  COOPERATION, 

ALL  OF  YOU  ARE  AWARE  OF  THE  PRESSURES  CURRENTLY  BEING 
PLACED  ON  THE  DEPARTMENT  OF  DEFENSE  BY  THE  CONGRESS  TO  INCREASE 
COMPETITION  FOR  SPARE  PARTS.  I  AM  SURE  YOU  HAVE  BEEN  EXPOSED  TO 
AT  LEAST  SOME  OF  THE  TELEVISION  AND  PRINT  MEDIA  EXPOSES  ON  OUR 
FAILURES  TO  COMPETE  SPARE  PARTS  BUYS  AND  THE  EXAMPLES  GIVEN  WHICH 
WERE  INTENDED  TO  SHOW  MILITARY  WASTE  AND  EXCESSIVE  EXPENDITURES. 
PERHAPS  YOUR  COMPANY  HAS  BEEN  ONE  OF  THOSE  ACCUSED  OF  PRICE 
GOUGING  AND  EXCESSIVE  PROFITEERING  ON  THE  SALE  OF  SPARE  PARTS 
TO  THE  MILITARY.  IN  MANY  OF  THE  EXAMPLES,  THE  EXPOSE  IS  CORRECT. 
COMPETING  THE  ITEM  WOULD  HAVE  RESULTED  IN  A  LOWER  PRICE.  THEN, 
WHY  DIDN'T  WE  COMPETE  THE  ITEM?  I  AM  NOT  GOING  TO  ATTEMPT 
TO  ANSWER  THAT  FOR  ALL  CASES,  BUT  I  DO  WANT  TO  DISCUSS 
ONE  MAJOR  REASON.  THE  OBSTACLE  TO  COMPETITION  OF  WHICH  I  AM 
SPEAKING  IS  THE  LACK  OF  ADEQUATE  TECHNICAL  DOCUMENTATION. 

ALL  TOO  OFTEN,  THE  TECHNICAL  DATA  DELIVERED  TO  THE  NAVY 
DOES  NOT  DISCLOSE  SUFFICIENT  DETAIL  TO  SUPPORT  REPROCUREMENT 
OF  IDENTICAL  SPARE  AND  REPAIR  PARTS  FROM  OTHER  THAN  THE 
ORIGINAL  EQUIPMENT  MANUFACTURER  (OEM).  THIS  IS  ALMOST  THE 
WAY  OF  LIFE  FOR  US  WITH  REGARD  TO  CONTRACTOR  FURNISHED 
EQUIPMENT  WHERE  THE  DATA  OFTEN  DOES  NOT  EXIST  TO  THAT  LEVEL 
OF  DETAIL,  BUT  IT  IS  ALSO  FREQUENTLY  THE  CASE  WITH  GOVERNMENT 
FURNISHED  EQUIPMENT  EVEN  THOUGH  THE  NAVY  SUPPOSEDLY  BOUGHT  THE 
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REQUIRED  DATA.  IN  MANY  CASES,  WE  HAVE  FOUND  THAT  LEVEL  III 
DRAWINGS,  WHERE  AND  WHEN  BOUGHT,  ARE  NOT  COMPLETELY  SUITABLE 
FOR  COMPETITIVE  REPROCUREMENT. 

LET'S  FACE  FACTS.  THE  PRESSURES  TO  BREAK  OUT  SPARE  PARTS 
FOR  COMPETITION  ARE  NOT  GOING  TO  LESSEN.  ON  THE  CONTRARY,  I 
EXPECT  THAT  THE  SCREWS  WILL  BE  TIGHTENED  EVEN  MORE  BY  CONGRESS 
AND  THE  HEAT  WILL  FURTHER  INCREASE.  EACH  OF  THE  SERVICES,  AS 
WELL  AS  DLA,  HAS  BEEN  GIVEN  GOALS  FOR  COMPETITION  WHICH 
SIGNIFICANTLY  EXCEED  THE  DOLLAR  VALUE  OF  THEIR  REPORTED 
COMPETITIVE  SPARE  PROCUREMENTS  OF  PRIOR  YEARS. 

HOW  IS  THE  NAVY  LOOKING  TO  MEET  THOSE  GOALS  FOR  COMPETITIVE 
PROCUREMENT  OF  SPARE  PARTS  FOR  SHIPS'  EQUIPMENT?  ONE  LONG-TERM 
OBJECTIVE  IS  TO  "ENCOURAGE"  ACQUISITION  MANAGERS  TO  BUY  MORE 
DETAILED  TECHNICAL  DATA  WITH  THE  EQUIPMENT  PROCUREMENT.  ANOTHER 
OBJECTIVE,  ALSO  LONG-TERM,  BEING  PURSUED  BY  NAVSEA  IS  TO  DEVELOP 
STANDARDIZED,  NAVY  OWNED  DESIGNS  FOR  CERTAIN  COMMON,  HIGH 
POPULATION,  HlM&E  EQUIPMENTS.  A  THIRD  ACTION,  WHICH  MY  ACTIVITIES 
ARE  BEING  LOOKED  TO  FOR  GREATER  INVOLVEMENT,  IS  THE  IN-DEPTH 
TECHNICAL  REVIEW  OF  EXISTING  DOCUMENTATION  TO  DETERMINE  ADEQUACY 
FOR  COMPETITION  OR  TO  DEVELOP  ADDITIONAL  TECHNICAL  DATA  SO  THAT 
THE  PACKAGE  IS  ADEQUATE  TO  COMPETE. 

ANOTHER  ACTION,  AND  ONE  WHICH  IS  ACTIVELY  BEING  PURSUED  BY 
SPCC,  IS  THE  DEVELOPMENT  OF  INCREASED  COOPERATION  WITH  EQUIPMENT 
MANUFACTURERS. 
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THIS  LEADS  ME  INTO  MY  SECOND  THEME  -INCREASED  COOPERATION 
BETWEEN  THE  MILITARY  AND  INDUSTRY. 

WHAT  DO  I  MEAN  BY  INCREASED  COOPERATION? 

BEFORE  ANSWERING  THAT  QUESTION,  LET  ME  ASK.  YOU  A  FEW 
QUESTIONS.  OBVIOUSLY,  I  DON'T  EXPECT  ANSWERS. 

•  HOW  MANY  OF  YOUR  COMPANIES  ASSIGN  YOUR  OWN  PART 
NUMBER  TO  ALL  PARTS  IN  EQUIPMENT  YOU  PRODUCE  EVEN  THOUGH  YOU 
DO  NOT  MAKE  ALL  THE  PARTS  YOURSELF  BUT  PURCHASE  THEM  FROM  SOME 
VENDOR  OR  VENDORS? 

•  HOW  MANY  OF  YOUR  COMPANIES  PURPOSELY  LEAVE  SOME  OF 
THE  DETAILS  OF  A  MANUFACTURING  PROCESS,  QA  REQUIREMENT,  TEST 
PROCEDURE  OR  MATERIALS  REQUIREMENT  OFF  A  PART  DRAWING  SO  WE 
WILL  HAVE  TO  COME  BACK  TO  YOU  TO  BUY  THE  PART? 

•  HOW  MANY  OF  YOUR  COMPANIES  CONSCIOUSLY  STRIVE  TO  GET 
YOURSELF  INTO  THE  POSITION  OF  BEING  THE  SOLE  SOURCE  FOR  SPARE 
PARTS  AND  THEN  CHARGE  EXCESSIVELY  HIGH  PRICES  FOR  THOSE  PARTS? 

•.  HOW  MANY  OF  YOUR  COMPANIES  PROFIT  MORE  ON 
GOVERNMENT  SALES  THAN  COMMERCIAL  SALES? 

•  WHY  SHOULD  THE  MILITARY  BE  PLACED  IN  THE  POSITION  OF 


BUYING  SPARE  PARTS  ONLY  FROM  YOUR  COMPANY  UNLESS  YOU  BRING  SOME 
SPECIAL  "MAGIC"  TO  THAT  PART? 

•  WHY  SHOULD  THE  MILITARY  PAY  YOUR  COMPANY  SIMPLY  TO 
PASS  AN  ORDER  FOR  SPARE  PARTS  THROUGH  TO  ONE  OF  YOUR  VENDORS? 

•  WHY  SHOULD  YOUR  COMPANY  MAKE  A  GREATER  PROFIT  OFF 
OF  MILITARY  SALES  THAN  COMMERCIAL  SALES? 

AS  I  SAID,  THE  PRESSURES  TO  COMPETE  SPARE  PARTS  ARE  NOT 
GOING  TO  GO  AWAY;  SO  WE,  THE  MILITARY  AND  INDUSTRY,  MUST  WORK 
TOGETHER  IN  WAYS  WHICH  ARE  MUTUALLY  BENEFICIAL  WHICH  WILL  HELP 
US  TO  MEET  OUR  GOALS  FOR  COMPETITION,  AND  WHICH  WILL  REDUCE 
THE  COSTS  FOR  SPARE  PARTS. 

mr.  dick  McFarland,  the  executive  director  at  spcc,  is 

CURRENTLY  CONTACTING  SENIOR  EXECUTIVES  AT  MAJOR  COMPANIES  AMD 
PROPOSING  THAT  THEY  RELEASE  TO  NAVY  THE  DATA  ON  VENDOR  ITEMS 
FOR  WHICH  THE  EQUIPMENT  MANUFACTURER  ADDS  NO  MAGIC"  OR  "VALUE," 
TECHNICAL  DATA  PACKAGES,  SOURCES  AND  PRICING  STRUCTURE  OH  AH 
ITEM  BY  ITEM  BASIS.  WHERE  HE  HAS  ALREADY  GOTTEN  SUCH  AGREEMENTS, 
SPCC  HAS  BEEN  ABLE  TO  REDUCE  LEAD  TIMES  AS  WELL  AS  REDUCE  COSTS 
TO  NAVY. 

WHAT  DOES  THE  COMPANY  GET  IN  EXCHANGE  FOR  THIS  INCREASED 
COOPERATION  OTHER  THAN  SIMPLY  SEEING  A  DECREASE  IN  TAX  DOLLARS 


BEING  SPENT  FOR  SPARE  PARTS?  MR.  McFARLAND  IS  PROVIDING  TO 
THOSE  COMPANIES  WITH  WHICH  HE  HAS  NEGOTIATED  AGREEMENTS  PROJECTED 
ANNUAL  BUY  DATA  FOR  THOSE  LEGITIMATE  SOLE  SOURCE  ITEMS  SO  THAT 
THE  COMPANY  MAY  BETTER  PLAN  FOR  AND  PRODUCE  TO  THOSE  LARGER 
ANNUAL  BUYS.  FURTHER,  HE  IS  WORKING  ON  A  PROGRAM  TO  TRANSLATE 
PRODUCTION  PLANNING  FORECASTS  INTO  ONE  TIME  PRODUCTION  CONTRACTS. 
IN  ADDITION,  PROGRAMS  ARE  NOW  GETTING  UNDERWAY  UNDER  NAVMAT'S 
SPONSORSHIP  WHICH  WILL  IDENTIFY  PARTS  WHICH  ARE  "CRITICAL"  TO 
THE  OPERATION  OF  THAT  EQUIPMENT  AND  THEN  LIMIT  THE  PROCUREMENT 
OF  THOSE  PARTS  RATHER  THAN  BREAKING  THEM  OUT  FOR  COMPETITION. 
FUTURE  EQUIPMENT  CONTRACTS  WILL  INCLUDE  THE  REQUIREMENT  FOR 
THE  EQUIPMENT  MANUFACTURER  TO  RECOMMEND  SPECIFIC  PROCUREMENT 
METHOD  CODES  (PMC)  FOR  EACH  PART  IN  ACCORDANCE  WITH  MILITARY 
STANDARD  789.  NAVELEX  IS  STARTING  TO  INCLUDE  THIS  REQUIREMENT 
IN  THEIR  CONTRACTS  AND  I  EXPECT  NAVSEA  TO  ALSO  DO  SO  IN  THE  NOT 
TOODISTANT  FUTURE. 

THIS  MAY  NOT  BE  WHAT  YOU  EXPECTED  TO  HEAR  FROM  THE  NAVY 
REPRESENTATIVE  TODAY.  BUT,  WHEN  YOU  GET  A  SIMPLE  "SHIP  DRIVER" 
TALKING  ABOUT  SUCH  THINGS  AS  COMPETITION,  PROCUREMENT, 
REPROCUREMENT,  FIRST  TIER  BREAKOUT,  AMD  TECHNICAL  DOCUMENTATION, 
WHAT  CAN  YOU  EXPECT?  MY  BOTTOM  LINE  ALWAYS  IS  IMPROVED  SUPPORT 
FOR  THE  FLEET. 
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WE  HAVE  BOTH,  MILITARY  AND  INDUSTRY,  TAKEN  ENOUGH  HITS 
AND  BEEN  GIVEN  ENOUGH  BLACK  EYES  BY  THE  MEDIA  ON  LACK  OF 
COMPETITION  FOR  SPARE  PARTS.  THE  DRIVE  FOR  INCREASED 
COMPETITION  IS  HERE  TO  STAY.  WE  NEED  TO  GET  ON  WITH  IMPROVING 
THE  COOPERATION  BETWEEN  THE  MILITARY  AND  INDUSTRY  SO  THAT  MY 
BOTTOM  LINE  OF  IMPROVED  SUPPORT  TO  THE  FLEET  CAN  BE  ACHIEVED. 

THANK  YOU 
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GOOD  MORNING.  LADIES  AND  GENTLEMEN-  i  AM  LTC  STEPHEN  TRACT,  FROM  THE  DIRECTORATE  FOR 
READINESS,  HEADQUARTERS,  DARCOM,  AND  [  HILL  BE  BRIEFING  YOU  TODAY  ON  AN  EVOLUTIONARY 
CONCEPT  BEING  DEVELOPED  BY  QARCOM  HH1CH  HILL  AUTOMATE  TECHNICAL  DATA  FROM  THE  HEAPONS 
SYSTEM  DESIGNER  TO  THE  SOLDIER  IN  THE  FIELD-  THIS  NEW  CONCEPT  FOR  MANAGEMENT  OF 
TECHNICAL  DATA  HILL  UTILIZE  THE  TREMENDOUS  POTENTIAL  OF  RECENT  COMPUTER  TECHNOLOGICAL 
ADVANCES  IN  BOTH  HARDWARE  AND  SOFTWARE  IN  THE  COMMERCIAL  SECTOR.  THE  DEVELOPMENT  OF 
THIS  CONCEPT  IS  CONSIDERED  BY  DARCOM  TO  BE  A  MAJOR  INITIATIVE  UNDER  THE  LOGISTICS 
RESEARCH  AND  DEVELOWENT  PROGRAM. 


TECHNICAL  DATA  MANAGEMENT 

TYPICAL  WEAPON  SYSTEM 
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The  need  for  automated  technical  data  is  obvious. 


r 


TECHNICAL  DATA  IS  EXPLODING  IN  VOLUME. 


FOR  EXAMPLE.  TECHNICAL  DOCUMENTATION  HAS  EXPLODED  FROM  3000  PA6ES  FOR  THE  M2A  TANK 
IN  19H0,  TO  15.000  PAGES  FUR  THE  M60  TANK  IN  THE  70' S,  TO  ABOUT  32.000  PAGES  IN 
THE  30'S  FOR  THE  Ml  TANK.  THE  PATRIOT  MISSLE  USERS  LIKEWISE  ARE  CONFRONTED 
WITH  21.000  PAGES  OF  MANUALS  FOR  THEIR  WEAPON  SYSTEM-  BUT  THESE  ARE  ONLY 
TWO  EXAMPLES  OF  THE  TOTAL  PROBLEM  CONFRONTING  THE  ARMY.  ADD  TO  THIS.  TECHNICAL 
MANUALS  FOR  OTHER  NEW  SYSTEMS  BEING  FIELDED  OVER  THE  NEXT  SEVERAL  YEARS.  AND 
WE  FIND  THE  SOLDIER  IS  GOING  TO  NEED  TO  CARRY  AROUND  AN  EVER-INCREASING 
REFERENCE  LIBRARY  TO  KEEP  EQUIPMENT  SHOOTING,  MOVING.  AND  COMMUNICATING. 
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IF  WE  LOOK  AT  TECHNICAL  DATA  FROM  A  TOTAL  ARMY  VIEWPOINT,  THE  STORY  IS  EQUALLY  UNNERVING- 
LOOKING  ONLY  AT  THE  TOTAL  NUMBER  OF  ENGINEESfllRAWINGS  QN  APERATURE  CARDS  WITHIN  THE  ARMY 
TODAY,  THE  PICTURE  IS  ALL  BUT  MIND  BOGGLING-  IF  THESE  CARDS  WERE  PLACED  IN  A  SINGLE 
STACK,  THE  PILE  WOULD  TOWER  OVER  THE  WASHINGTON  MONUMENT  BY  SOME  100  FEET.  IF  THESE 
DRAWINGS  WERE  TO  BE  PLACED  ON  VIDEO  DISKS,  THE  700  FEET  OF  APERATURE  CARDS  WOULD  BE 
REDUCED  TO  420  OPTICAL  DISKS,  WHICH  WOULD  BE  ROUGHLY  8  FEET  HIGH,  IF  STACKED  ONE  ON  IOP 
OF  EACH  OTHER- 

IF  WE  CONTINUE  WITH  OUR  PRESENT  SYSTEM,  BY  THE  YEAR  2000,  ENGINEER^DRAWINGS  WILL 
INCREASE  FROM  THE  CURRENT  4-3  MILLION  APERATURE  CARDS  TO  13-3  MILLION  -  A  3  FOLD  INCREASE 
IN  LESS  THAN  20  YEARS-  BY  THE  YEAR  2000,  THE  STACK  OF  APERATURE  CARDS  WOULD  APPROACH 
2100  FEET  IN  HEIGHT  -  THE  APPROXIMATE  COMBINED  HEIGHT  OF  BOTH  THE  UPPER  ANO  LOWER  FALLS 
AT  YOSEMITE  NATIONAL  PARK!!  AND  THIS  WOULD  ONLY  BE  A  SMALL  PORTION  OF  THE  OVERALL  TECH¬ 
NICAL  DATA  VOLUME  WITHIN  THE  ARMY!!! 

FOR  YOUR  INFORMATION,  DSREDS  NOTED  ON  THE  UPPER  RIGHT  HAND  PORTION  OF  THIS  SLIDE  IS  AN 
ACRONYM  FOR  DIGITAL  STORAGE  AND  RETRIEVAL  ENGINEER  DATA  SYSTEM,  WHICH  IS  A  PROPOSED 
SYSTEM  WE  ARE  EXAMINING  WHICH  PROMISES  TO  REDUCE  THE  VOLUME  OF  PAPERWORK  FOR  ENGINEERING 
DRAWINGS- 


TECH  INI  I  CAL  DATA  MANAGEMENT 

REJ1U±REMENTS 


SYSTEM  SHOULD  INCLUDE: 


•  TECH  OATA  PACKAGE 

•  LOGISTICS  SUPPORT  ANALYSIS 
•  TECHNICAL  MANUALS 

•  REPAIR  PARTS  ANO  SPECIAL  TOOLS  UST 
•  TRAINING  MATERIALS 
•  TRAINING  DEVICES 
•  PROCESS  SHEETS 


•  DEPOT  MAINTENANCE  WORK  REQUIREMENTS 

•  DIAGNOSTICS/ATE 

•  PARTS  REQUISITIONING  CAPABILITY 

•  MAINTENANCE  DATA  COLLECTION 

•  ADAPTABILITY  FOR  FOUOW-ON 
TRAINING/TESTING 
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APERAiURE  CARDS  AND  HARD  COPY  TECHNICAL  MANUALS  ARE  ONLY  PART  OF  THE  PROBLEM  TODAY  IN 
FIELDING  AND  SUPPORTING  NEW  WEAPONS  SYSTEMS.  THE  FACT  IS  THAT  THE  WHOLE  TECHNICAL  DATA 
SYSTEM  IS  OUTMODED  AND  MUST  8£  FIXED;  INCLUDING  THE  TECHNICAL  DATA  PACKAGE.  REPAIR  PARTS 
LISTING  AND  REQUISITIONING,  TRAINING  PUBLICATIONS.  DEPOT  MAINTENANCE  WORK  DOCUMENTS. 

U1AGHQSTIC  fault  isolation,  and  even  feemack  of  field  maintenance  data  to  the  supplier 

AND  DESIGNER. 

CURRENT  TECHNOLOGY  IS  NOW  AVAILABLE  TO  STREAMLINE  THE  ENTIRE  PROCESS;  AND  WHAT  WE  NEED 
IS  A  CONCEPT  THAT  TIES  ALL  THE  PIECES  TOGETHER. 

THE  COMMANDER  OF  DARCOH,  GENERAL  KEITH,  HAS  DIRECTED  THAT  ACTION  BEGIN  IMMEDIATELY 
TO  EXPEDITE  DEVELOPMENT  OF  A  MODERNIZED  TECHNICAL  DATA  MANAGEMENT  SYSTEM.  THAT  EFFORT 
IS  UNDERWAY  NOW,  AND  INVULVES  BOTH  DARCOM  AND  TRADOC-  IN  THE  REMAINDER  OF  THE  BRIEFING, 
t  WILL  IDENTIFY  INITIATIVES  ALREADY  UNDERWAY  TODAY,  ANQ  WILL  SHOW  YOU  WHAT  NEEDS  TO  BE 
DONE- 


TECHNICAL  DATA  MANAGEMENT 

KNOWN  ARMY  INITIATIVES 

•  COMPUTER-ASSISTED  DESIGN/COMPUTER-ASSISTED  MANUFACTURING 

•  CONFIGURATION  TECHNICAL  OATA 

•  STORAGE  OF  DIGITIZED  ENGINEERING  DRAWINGS 

•  LOGISTICS  SUPPORT  OATA 

•  PROVISIONING  DATA  -  REDESIGN  OF  CURRENT  SYSTEM 

•  MAINTENANCE  DATA  FEEDBACK 

•  EQUIPMENT  PUBLICATIONS  PRODUCTION  SYSTEM 

•  USER  ELECTRONIC  DISPLAYS  -  PARTS  AND  MAINTENANCE  DATA 
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THESE  ARE  ON-GOING  INITIATIVES  IN  THE  ARMY  THAT  RELATE  DIRECTLY  TO  THE  PROBLEM  OF 
TECHNICAL  DATA-  THESE  ARE  ALREAOY  EXISTING  PROJECTS  THAT  MUST  BE  LINKED  TOGETHER- 
IN  SOME  INSTANCES  THEY  REQUIRE  NEW  STATE-OF-THE-ART  HARDWARE.  WHILE  OTHERS  REQUIRE 
SOFTWARE  DESIGN.  THEY  ARE  MAJOR  EFFORTS  THAT  WILL  BE  CRITICAL  TO  SOLVING  THE 
ENTIRE  TECHNICAL  DOCUMENTATION  PROBLEM-  I'D  LIKE  TO  DISCUSS  SOME  OF  THEM  WITH 
YOU  NOW.  IN  THE  CONTEXT  OF  THE  MANNER  IN  WHICH  THE  TECHNICAL  DATA  MUST  FLOW  IN 
UARCQM. 


TECHNICAL  DATA  MANAGEMENT 

TECHNICAL  DATA  STORAGE  SYSTEM 
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FOR  INSTANCE,  DARCOM  HAS  A  PROJECT  UNDERWAY  NOW  TO  PROVIDE  A  NEW  STORAGE  MEDIUM  FOR  THE 
MILLIONS  OF  ENGINEERING  DRAWINGS  OUR  SUBORDINATE  COMMANDS  MUST  STORE  ON  OUTDATED  55  MM 
APERA TliRE  CARDS ■  THE  STATE-OF-THE-ART  IS  HERE  FOR  A  SYSTEM  USING  OPTICAL  VIDEODISCS  AS 
THE  STORA'.-'  MEDIUM.  THE  PROPOSED  SYSTEM,  CALLED  THE  DIGITAL  STORAGE  AND  RETRIEVAL 
ENGINEERING  DATA  SYSTEM  -  DSREDS  -  COULD  AUTOMATICALLY  ASSEMBLE  ALL  APPLICABLE  DRAWINGS 
FOR  EACH  TECHNICAL  DATA  PACKAGE  IDENTIFIED  FOR  PROCUREMENT,  AS  WELL  AS  BE  THE  TECHNICAL 
BASE  FOR  INSTRUCTIONAL  MANUALS- 

COMPUTES  ASSISTED  THREE  DIMENSIONAL  DESIGN  TECHNIQUES,  IN  USE  BY  SOME  MAJOR  INDUSTRIAL 
CONCERNS,  COULD  THEN  BE  LINKED  TO  THIS  SYSTEM;  AND  THROUGH  THE  ABILITY  OF  INTERACTIVE 
GRAPHICS,  WOULD  ALLOW  THE  DESIGN  ENGINEER  TO  ‘TALK*  TO  HIS  DRAWINGS  AND  KEEP  THEM 
CURRENT. 


AUTOMATED  PRINTING  AND  PUBLISHING  SYSTEM  (APPS) 


text  ENtRY/EOIt  TEAMINAl 


LASER  CAMERA 


PHI)  10  nPECf  >’tR 
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ANOTHER  PROJECT  INVOLVES  AUTOMATING  THE  PRINTING  OF  TECHNICAL  PUBLICATIONS. 

IN  JANUARY,  DARCQM'S  MISSILE  COMMAND  (H1C0M)  TURNED  ON  A  PILOT  SYSTEM  WHICH  HILL  HELP 
SOLVE  THE  PROBLEM  WITH  TECHNICAL  PUBLICATIONS,  INSOFAR  AS  THE  BACKLOG  IN  PRINTING  IS 
CONCERNED.  IT  IS  A  SOPHISTICATED  WORD  PROCESSING  SYSTEM  WHICH  STORES  WORDS  AND  PIC¬ 
TURES  ON  TAPES  AND  ALLOWS  THE  MAINTENANCE  ENGINEER  TO  DISPLAY  THEM  FOR  EDITING  AND 
THEN  PROVIDES  AN  OUTPUT  FOR  PRINTING.  SHOWN  HERE  ARE  THE  OFF-THE-SHELF  PRODUCTS 
WHICH  MAKE  UP  THE  PROTOTYPE  AUTOMATED  PRINTING  AND  PUBLICATIONS  SYSTEM- 

THE  SYSTEM  WILL  HAVE  OUTPUT  CAPABILITY  INITIALLY  ONLY  TO  PRINT  HARD  COPY.  AN  EARLY 
SYSTEM  ENHANCEMENT  WILL  ADO  THE  ABILITY  TO  OUTPUT  ELECTRONICALLY-  HOWEVER,  THIS 
METHOD  WILL  NOT  PROVIDE  THE  SOLDIER  WITH  AUTOMATED  PUBS-  IN  ORDER  TO  REPLACE 
THE  WRITTEN  WORD,  WE  MUST  HAVE  DISPLAY  TERMINALS  IN  THE  FIELD- 


the  first  step  hill  be  to  provide  an  interim  solution  until  more  refined  versions  can 

BE  FIELDED.  HE  ARE  THINKING  OF  SOMETHING.  PERHAPS  RACK-SIZE.  WITH  TAPE  OR  EVEN  DISC 
STORAGE.  LIKE  HHAT  IS  SHOWN  ON  THIS  VUGRAPH.  IT  COULD  BE  UTILIZED  FOR  BOTH  SMALL 
DENSITY  SYSTEMS,  LIKE  THE  PATRIOT,  AND  ALSO  FOR  APPLICATION  WITH  LAR6ER  DENSITY 
SYSTEMS- 

IT  IS  "VhE  USE  OF  SUCH  A  DEVICE  THAT  HE  ARE  WORKING  CLOSELY  WITH  TRADOC  AND  THE 
LOGISTICS  CENTER. 


I 


LOOKING  OUT  BEYOND  THE  INTERIM  SOLUTION,  WE  ARE  DEVELOPING,  WITH  TRADOC,  MORE  PORTABLE 
SYSTEMS  FOR  FIELD  USE-  I  WILL  BRIEFLY  MENTION  TWO-  FIRST.  THE  ELECTRONIC  INFORMATION 
DELIVERY  SYSTEM,  WHICH  IS  A  PORTABLE  VIDEO  DISC  SYSTEM  UNDER  DEVELOPMENT  BY  DARCOM 
WITH  FULL  SCALE  PRODUCTION  POSSIBLE  IN  1987. 


TECHNICAL  DATA  MANAGEMENT 

INFORMATION  DELIVERY  CONCEPT 


MICROPHONE/ 

HEADPHONE 

SET 


HAND-HELD 

DISPLAY/ 

RESPONSE 

UNIT>>\ 


SPECIAL 
FUNCTION 

KEYS  MICROPHONE 
PLUG 


MASS 

STORAGE 

DEVICE 


FLAT  PANEL  f 

DISPLAY  MODULAR 

PHONE  PLUG 


REMOVABLE 

MASS 

STORAGE 


A/C 

POWER  PLUG 


ANOTHER  SYSTEM,  UNDER  DEVELOPMENT  3Y  ARMY  RESEARCH  INSTITUTE  (ARI ),  IS  A  PORTABLE  VIDEO 
CASSETTE  SYSTEM  CALLED  PEAM  (£ERSONAL  ELECTRONIC  AID  FOR  &AINTENANCE)-  THIS  IS  A  JOINT- 
SERVICE  PR06RAM  WITH  ARI  AS  THE  PROGRAM  MANAGER.  TEXAS  INSTRUMENT  HAS  AWARDED  A  CONTRACT 
TO  PROVIDE  FOUR  PROTOTYPES.  (THREE  FOR  ARMY.  AND  ONE  FOR  NAVY)  IN  1984  WITH  PRODUCTION 
POSSIBLE  IN  1987- 

BEYOND  THESE  ON-GOING  EFFORTS,  DARCOM  HAS  ASSEMBLED  A  TECHNICAL  DATA  MANAGEMENT  TASK 
GROUP  THAT  HAS  DESIGNED  A  NEW  TECHNICAL  DATA  MANAGEMENT  SYSTEM  CONCEPT-  THESE  ON-GOING 
EFFORTS  FIT  INTO  THIS  CONCEPT-  I'D  LIKE  TO  BRIEFLY  SHOW  YOU  WHAT  THE  CONCEPT 
ENTAILS.  BEGINNING  AT  THE  ORGANIZATIONAL  LEVEL  OF  THE  ARMY- 


TeCH  DATA  AuxMnATiGH 


KfTAlL  LEVEL 


LET  US  BEGIN  THE  DISCRETION  OF  THIS  CONCEPT  AT  THE  ORGANIZATION  LEVEL-  THE  BASIC  MEDIA 
WHICH  WOULD  BE  USED  TO  DISTRIBUTE  THE  MAINTENANCE, INFORMATION  WOULD  BE  A  VIDEO  DISC- 
TO  ACCESS  THIS  INFORMATION,  A  SYSTEM  WOULD  BE  RACK  MOUNTED  IN  EACH  MAINTENANCE  VAN; 

1)  A  MICRO  COMPUTER,  2)  A  VIDEO  DISC  PLAYER,  3)  A  VIDEO  DISPLAY,  H)  AN  IMPACT  PRINTER, 
ano  5)  A  FLOPPY  DISC  DRIVE-  TO  ACCESS  THE  NEEDED  INFORMATION,  THE  TECHNICIAN  WOULD 
PVLL  THE  APPROPRIATE  DISC  FROM  THE  STORED  LIBRARY  AND  DISPLAY  THE  NEEDED  INFORMATION 
FOR  REVIEW  AND  STUDY-  THAT  INFORMATION  WHICH  IS  NEEDED  TO  BE  TAKEN  BACK  TO  THE  JOB 
( f .£. ,  SCHEMATICS,  TEST  CONDITIONS,  ETC--.)  CAN  BE  PRINTED  OUT  AND  REMOVED  FOR  HIS 
PERSONAL  USE- 

AT  THE  INTERMEDIATE  LEVEL,  WE  ENVISION  THE  SAME  SYSTEM  BEING  USED-  THE  ONLY  DIFFERENCE 
WOULD  BE  MORE  UNITS  AND  A  LARGER  LIBRARY-  THE  INFORMATION  CONTAINED  ON  THE  DISC  WOULD 
HAVE  ALL  LEVELS  OF  MAINTENANCE,  THUS,  THE  DISCS  USED  AT  ALL  LEVELS  WOULD  BE  THE  SAME- 

IT  IS  AT  THE  ORGANIZATIONAL  ANO  INTERMEDIATE  LEVELS  THAT  WE  SEE  THIS  SYSTEM  PROVIDING 
INPUT  TO  THE  SUPPLY  SYSTEM- 


THE  SYSTEM  CONCEPT  ALSO  INCLUDES  A  CAPBILITY  TO  RESPOND  TO  MEET  UNFORESEEN  PROBLEMS- 
THAT  IS,  THE  PROBLEMS  THAT  CANNOT  BE  DIAGNOSED  AND  FIXED,  USING  THE  INFORMATION  IN 
THE  MAINTENANCE  DISC-  WE  FORESEE  THE  USE  OF  NEAR  REAL  TIME  COMMUNICATIONS  TO  RELAY 
THE  PROBLEM  TO  THE  RESPONSIBLE  MSC-  AT  THE  RECEIPT  OF  THE  PROBLEM,  THE  SYSTEMS 
ENGINEERING  STAFF  WILL  ADDRESS  THE  PROBLEM  AND  DEFINE  A  ‘FIX'-  THIS  ‘FIX'  WILL 
BE  RETURNED  TO  THE  FIELD  USING  NEAR  REAL  TIME  COMMUNICATIONS-  THE  SYSTEM  WILL 
RETAIN  BOTH  THE  PROBLEM  AND  FIX  FOR  FURTHER  REFERENCE  AND  INCLUSION  IN  THE 
CHANGES  THAT  WOULD  BE  MADE  IN  THE  NEXT  VERSION  OF  THE  MAINTENANCE  DISC  TO  GO 
TO  THE  FIELD- 


TECH  OAT  A  AUTOMATION 
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HERE  WE  DEPICT  THE  FRONT-END  OF  THE  SYSTEM  WHERE  THE  VIDEO  DISCS  ARE  CREATED  AND  CON¬ 
TROLLED-  LET  US  IMAGINE  THAT,  WHEN  WE  CONTRACT  FOR  THE  DEVELOPMENT  OF  A  SYSTEM,  WE 
ASK  FOR  DIGITAL  DATA  DELIVERED  IN  THE  FORM  OF  A  MAGNETIC  TAPE  OR  VIDEO  DISC  -  NO 
PAPER;  THAT  IS,  ALL  OF  THE  TECHNICAL  DATA  DRAWINGS,  SPECIFICATIONS,  DESCRIPTIVE 
ANO  TRAINING  INFORMATION  IS  IN  DIGITAL  FORMAT-  MOREOVER,  LET  US  FURTHER  ASSUME 
THAT  WE  CAN  DEFINE  A  HIGHER  ARCHIVAL  SET  OF  DATA  FROM  WHICH  ALL  REQUIRED  INFORMATION 
CAN  BE  DERIVED.  THE  SYSTEM  AT  THE  MSC  WILL  CONSIST  OF  THE  FOLLOWING  SUB-ELEMENTS: 

1)  A  MAIN  FRAME  COMPUTER,  2)  A  VIDEO  DISC  JUKE  BOX,  3)  AN  OPTICAL  DISC  READ/WRITE 
UNIT,  4)  WORK  STATIONS,  ANO  5)  INPUT  UNITS  FOR  MAGNETIC  TAPE,  OPTICAL  DISC  OR 
PAPER  (THE  OPTICAL  SCANNER)-  THIS  SYSTEM  WOULD  ENABLE  THE  NSC  TO  INPUT  THE 
INFORMATION  INTO  AN  ARCHIVAL  MEDIA  VIDEO  DISC.  AND  RECALL  THAT  INFORMATION  (TEXT 
AND  DRAWINGS)  AT  THE  WORK  STATIONS  ANO  CHANGE  IT  ON  A  ROUTINE  BASIS-  THEN, 
PERIODICALLY,  PRODUCE  A  NEW  DISC  FOR  DISTRIBUTION  TO  THE  USER  ORGANIZATIONS,  THE 
OEPOTS  AND  OTHER  DARCOM  ORGANIZATIONS-  THE  KEY  TO  THE  ABOVE  CONCEPT  IS  THE 
NEED  TO  DEFINE  THE  HIGHER  ARCHIVAL  DATA  BASE,  ITS  FORMAT  AND  INTERFACE- 

THE  SYSTEM  AT  THE  DEPOT  LEVEL  IS  ENVISIONED  TO  BE  DIFFERENT  THAN  AT  THE  MSC 
BECAUSE  OF  THE  DIFFERENCES  IN  NEEDS-  THE  DISC  LIBRARY  WILL  AGAIN  BE  ACCESSED 
BY  THE  JUKE  BOX,  BUT  THE  SYSTEM  WILL  BE  CONTROLLED  THROUGH  A  MINI-COMPUTER- 
THE  SYSTEM  WILL  ALLOW  DESIGN  CHANGES  BE  MADE  ON  A  CAD/CAM  SYSTEM  AND  THEN 
BE  INTRODUCED  TO  THE  SYSTEM  AND  FINALLY  ENTERED  ON  AN  OPTICAL  DISC  FOR  STORAGE  AND 
RETRIEVAL-  SHOP  TECHNICIANS  WOULD  HAVE  ACCESS  TO  THE  STORED  INFORMATION  THROUGH 
REMOTE  TERMINALS  TIED  TO  THE  SYSTEM- 

SUCH  IS  OUR  TDM  SYSTEM  AS  WE  ENVISION  IT  TODAY-  WE  HAVE  A  GREAT  DISTANCE 
TO  TRAVEL  BEFORE  WE  REACH  OUR  GOAL  -  AN  AUTOMATED  TECHNICAL  DATA  MANAGEMENT 
SYSTEM.  WE  HAVE  A  BEGINNING-  WHAT  WILL  WE  BE  DOING  NEXT? 
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TECHNICAL  DATA  MANAGEMENT 

WHAT  NEEDS  TO  BE  DONE 


TRADOC  AND  DARCOM  WILL: 

•  DEFINE  APPROACH 

•  IDENTIFY  RESOURCES  REQUIRED 

•  ESTABUSH  SCHEDULE 

•  FORMULATE  DESIGN  CRITERIA 

•  FORMULATE  PROGRAM  PARAMETERS 

•  SELECT  NEAR  TERM  INITIATIVES 


GENERAL  KEITH  GAVE  APPROVAL  TO  THE  TECHNICAL  DATA  CONCEPT  ON  12  JANUARY  AND 
DIRECTED  THAT  THIS  EFFORT  BECOME  ONE  OF  DARCOM'S  MAJOR  THRUSTS  TO  BE  INCLUDED 
AS  PART  OF  THE  ARMY'S  NEW  LOGISTICS  RESEARCH  AND  DEVELOPMENT  INITIATIVES- 
DETAILS  ARE  BEING  WORKED  OUT,  BUT  THINGS  ARE  ALREADY  MOVING  FAST- 

DARCOM  AND  TRAOOC  ARE  NOW  WORKING  TOGETHER  ON  THE  NEWLY  CHARTERED 
TECHNICAL  DATA  MANAGEMENT  TASK  GROUP  TO  FURTHER  REFINE  THE  CONCEPT  AND  TO 
MANAGE  THE  ACTIONS  THAT  ARE  EITHER  UNDERWAY  OR  THAT  WILL  BEGIN  IN  THE 
FUTURE-  WE  WILL  PROBABLY  HIRE  A  CONTRACTOR  TO  DO  THE  DETAILED  WORK  OF 
DEFINING  INTERFACES,  FLESHING  OUT  THE  DETAILED  PLAN,  AND  PERFORMING  A 
COST  BENEFIT  ANALYSIS-  WHILE  THESE  ACTIONS  ARE  UNDERWAY,  THE  PM, 

PATRIOT  IS  FUNDING  AN  EFFORT  TO  USE  VIDEO  DISC  TECHNOLOGY  TO  PROTOTYPE 
A  TECHNICAL  DATA  DELIVERY  SYSTEM  FOR  THE  FIRST  BATTALION  THAT  RECEIVES 
THE  PATRIOT.  WE  WILL  BE  EVALUATING  THAT  EFFORT  CLOSELY  TO  SEE  HOW  IT 
WORKS  OUT- 

THAT  CONCLUDES  my  briefing-  are  thire  any  questions? 
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COMPUTER  AUTOMATION 

,cl_ of 

-  DESIGN  DATA 

AND 

TECHNICAL  SUPPORT  DATA 


PRESENTED  BY:  COLONEL  RALPH  L.  KUSTER,  JR. 

AFSC  ASD  /  AFWAt 


AUTOMATION  OF  DESIGN  AND  TECHNICAL  DATA 

PURPOSE 


TO  PRESENT  THE  RESULTS  OF  A  PRELIMINARY  REVIEW  OF 
AF  EFFORTS  WHICH  ARE  UNDERWAY  AND  PUNNED  TO 
DIGITIZE  AND  UTILIZE  AUTOMATED  TECHNICAL  DATA 
THROUGHOUT  THE  WEAPON  SYSTEM  LIFE  CYCLE 


SAF/AL  LTR,  3  SEP  82 


OUTLINE 


SAF/AL  CONCERNS 

•  PRELIMINARY  FINDINGS 

•  KEY  PROGRAMS  SYNOPSIS 

•  SUMMARY 


•  BACKGROUND 

•  ASSESSMENT  - 


AUTOMATION  OF  DESIGN  AND  TECHNICAL  DATA 

BACKGROUND 


•  BRIEFING  TO  SAF/ALG  31  AUG  82 

INTEGRATED  DESIGN  SUPPORT  SYSTEM  (IDSS) 

A  DIGITAL  SOFTWARE  DEVELOPMENT  PROGRAM  TO  COLLECT, 
MANAGE,  AND  CONTROL  FUTURE  WEAPON  SYSTEM  DESIGN  AND 
MANUFACTURING  DATA  FOR  LOGISTIC  SUPPORT 

•  SAF/AL  LETTER  TO  AF/CV  -  3  SEP  82 


•  BRIEFING  TO  SAF/AL  -  28  JAN  83 


OUTLINE 


•  BACKGROUND 

•  ASSESSMENT  -  SAF/AL  CONCERNS 

•  PRELIMINARY  FINDINGS 

•  KEY  PROGRAMS  SYNOPSIS 


•  SUMMARY 


AUTOMATION  OF  DESIGN  AND  TECHNICAL  DATA 

SAF/AL  CONCERNS 


ASSESSMENT  -  MASSIVE  DATA  FILES 
MASSIVE  MICROFILM  AND  PAPER 

•  MICROFILM  DRAWINGS  •  25.000.000  BEING  MAINTAINED  TO  DEPICT 
CONFIGURATION  OF  CURRENT  AIR  FORCE  SYSTEMS 

•  TECHNICAL  OROERS  •  13.000.000  PAGES  TO  CONTROL  OPERATION  AND 
MAINTENANCE  OF  AIR  FORCE  SYSTEMS 

TYPICAL  EXAMPLES: 


WEAPON 

MICROFILM 

TECH  OROER 

§YSTEM 

URAWINGS 

PAGES 

F-16 

555.000 

660.000 

F-111 

520,000 

624,000 

A-1Q 

110,000 

132,000 

F-4 

218.000 

500,000 

C-5 

150.000 

180,000 

SOURCE;  ARC/LOL 


L-3 


l 


AUTOMATION  OF  DESIGN  AND  TECHNICAL  DATA 

ASSESSMENT  -  MASSIVE  DATA  FILES 


COSTLY  TO  MAINTAIN  CURRENCY 

•  AFIC  FY83  BUDGET  FOR  MAINTENANCE  OF  TECH  ORDERS  •  $20,000,000 

•  TECH  ORDERS  CONVERTING  TO  TASK  ORIENTED  FORMAT 
(PAYOFF  TO  F4E/RF-4C  FLEET  IS  54  FLIGHT  READY  AIRCRAFT) 

•  $80,000,000  FOR  CHANGES  TO  MINUTEMAN  IC8M  TECH  ORDERS  (1966  •  1982) 

•  AVERAGE  COST  TO  PREPARE  A  TECH  ORDER  CHANGE  FOR  PRINTING 

•  $3,000  PER  PAGE  IF  ENGINEERING  IS  REQUIRED 

•  $160  -  400  PER  PAGE  •  DEPENDING  ON  CONTRACTOR 


SOURCE:  AFLC/LOL 


ASSESSMENT-WORD  PROCESSING  IN  INDUSTRY 

WORD  PROCESSING  IS  STATE-QF-ART 

WIDE  SPREAD  UTILIZATION  IN  INDUSTRY 
F-16,  B-1B,  MX  UTILIZING  TECHNOLOGY 

•  DEVELOPING  TECH  ORDERS  ON  DIGITAL  SYSTEM 


•  CURRENTLY  TRANSMITTED  VIA  PAPER  /  MICROFILM 


AUTOMATION  OF  DESIGN  AND  TECHNICAL  DATA 

ASSESSMENT  -  CAD/CAM  IN  INDUSTRY 


NUMBER  OF  TURNKEY  SYSTEM  INSTALLATIONS 
s  s  ° 

mo  in  o  §  o  §  =  ”  S 

TOP  tO  S  9  &  3  —  —  — ' 


ASSESSMENT  •  NAVY  DIRECTION 


•  295  COMPUTERVISION  CAD  I  CAM  SYSTEMS  •  FY83 

NAVY  AUTOMATED  VIDEO  INFORMATION  SYSTEM  (NAVIS) 

•  CAO  PROCESS  FOR  EN  ROUTE  A/C  REPAIR 

•  INSTALLED  ON  BOARD  CARRIER  SHIP 

•  AUGMENTED  BY  SATELLITE  TRANSMISSION 

•  EXPANSION  OF  AUTOMATED  VIDEO  MAINTENANCE 
INFORMATION  (AVMI)  SYSTEM 


\ AUTOMATION  OF  DESIGN  AND  TECHNICAL  DATA 

.  7  ASSESSMENT  -  CAD/CAM  IN  INDUSTRY 


TODAY’S  DESIGN  /  MANUFACTURING  COMPUTER  NETWORK 


•  INDIVIDUAL  ORGANIZATION  DATA  BASES 

•  DATA  BASE  STORED  ON  TAPE 

•  OATA  BASES  NOT  CURRENT 


INTERNAL 

LOAOS 


FATIGUE 


MATERIALS 


STRUCTURE  l 


SYSTEMS 


MASS  I  I  PROTOTYPE 
PROPERTIES 


MFG 

CONCEPT 


ASSESSMENT  -  CAD/CAM  DATA  FLOW 


DESIGN 


DESIGNER  AT 

DRAFTING 

BtMRO 


DESIGNER  I 
COMPUTER 
STATION 


•  OATA 

•  DESIGN 

•  MANUFACTURE 

•  OPERATIONS 

•  OATA  MEDIUMS 


MANUFACTURE 


•  NIC  PROGRAMMING 

•  TOOL  DESIGN  ' 

•  MFG  ENGINEERING 

•  ASSEMBLY 

CAD  I  CAM  N 


LOGISTICS 


•  DEPOT /nao  MAINTENANCE 

•  BATTLE  OAMAGE  REPAIR 

•  TAIL  NO  TRACKING 

•  OATA  MANAGEMENT 


SYSTEM  SUPPORT  DATA 


AUTOMATION  OF  DESIGN  AND  TECHNICAL  DATA 

ASSESSMENT -ISSUE  ?  ?  ? 


WHILE  DIGITAL  DESIGN  ANALYSIS  AND  GRAPHICS  USE  IS 
EXPLODING  IN  INDUSTRY,  THERE  IS  NO  CAPABILITY  TO 
CAPTURE  THIS  DATA  FOR  FUTURE  WEAPON  SYSTEM  LIFE 
CYCLE  MODIFICATIONS  AND  MAINTENANCE  !!! 


CAN  THE  AIR  FORCE  AFFORD  TO  LOSE  THIS  DATA  ? 


OUTLINE 


•  BACKGROUND 

•  ASSESSMENT  -  SAF/AL  CONCERNS 

•  PRELIMINARY  FINDINGS 

•  KEY  PROGRAMS  SYNOPSIS 


•  SUMMARY 


PRELIMINARY  FINDINGS 


•  AF  SPONSORING  MANY  PROGRAMS 
-  22  PROGRAMS  REVIEWED 

•  SOME  CONTROL  AND  MANIPULATE  DATA 

•  SOME  PROOUCE  DATA  AS  BY-PRODUCT 


•  AF  DOES  NOT  HAVE  A  FOCUSED  ^'AN  LEADING  TO  EXPLOITATION  OF 
GROWING  DIGITAL  TECHNOLOGY  IN  DESIGN,  MANUFACTURE.  AND  LOGISTICS 
SUPPORT 

•  VALUABLE  OATA  FOR  WEAPON  SYSTEM  MODIFICATION  AND  MAINTENANCE 
IS  NOT  CAPTURED  IN  TODAY’S  MICROFILM  I  PAPER  ENVIRONMENT 


OUTLINE 


•  BACKGROUND 

•  ASSESSMENT  -  SAF/AL  CONCERNS 

•  PRELIMINARY  FINDINGS 

»  KEY  PROGRAMS  SYNOPSIS 


•  SUMMARY 


•  7  KEY  PROGRAMS  THAT  CONTROL  &  MANIPULATE  DATA 

-  AUTONOMOUS  PROGRAMS 
•  NOT  COORDINATED 

•  THERE  IS  MINIMAL  DUPLICATION  OF  EFFORT 

•  HOWEVER,  THESE  PROGRAMS.  ARE  NOT  A  TOTAL  SOLUTION 
FOR  AUTOMATED  DESIGN  AND  TECHNICAL  DATA 

•  THEY  DO  ADORESS  THE  KEY  AREAS  OF  CONCERN 


KEY  RELATED  DATA  MANAGEMENT  PROGRAMS 


ORGANIZATION  PROGRAM  DEMONSTRATION 

AFLC  ENGINEERING  DATA  COMPUTER  AIDED  1985 

RETRIEVAL  SYSTEM 

AFHRL  UNIFIED  DATA  BASE  1983 

ARC  AUTOMATED  TECH  ORDER  SYSTEM  .  1984 

AFHRL  COMPUTER  BASED  MAINTENANCE  AIDS  1984 

AFHRL  MAINTENANCE  &  LOGISTICS  COMPUTER  1987 

AIDED  DESIGN 

AFWAL  INTEGRATED  DESIGN  SUPPORT  SYSTEM  1985 

USAFILEY  LOGISTIC  INFORMATION  MANAGEMENT 

SUPPORT  SYSTEM  1984 


AUTOMATION  OF  DESIGN  &  TECHNICAL  DATA 

KEY  RELATED  OATA  MANAGEMENT  PROGRAMS 


(AFIC) 


ENGINEERING  DATA  COMPUTER  AIDED  RETRIEVAL  SYSTEM 

PHASE  I:  CONVERT  EXISTING  35MM  APERTURE  ORAWINGS 

•  DIGITIZE  EXISTING  ORAWINGS  FOR  LIBRARY 

•  COMPATIBLE  WITH  EXISTING  TRANSMISSION  SYSTEMS 

•  INSTALL  AT  OEPOT  LEVEL 


PHASE  II: 


•  OESIGN  TO  ACCEPT  ANY  DATA  FORM  (PAPER.  DIGITAL) 

•  DISTRIBUTE  IN  ANY  OATA  FORM 


INSTALL  AT  BASE  LEVEL 


KEY  RELATED  DATA  MANAGEMENT  PROGRAMS 


UNIFIED  DATA  BASE  (AFHRL> 

•  ANALYZE  LOGISTICS  SUPPORT  ANALYSIS  RECORD 

•  ANALYZE  HISTORICAL  AND  PERFORMANCE  RECORDS 

•  PROVIDE  COMPENDIUM /TECHNOLOGY  BASE  FOR: 

•  MODIFICATIONS  . 

•  LESSONS  LEARNED 
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AUTOMATION  OF  DESIGN  &  TECHNICAL  DATA 

KEY  RELATED  DATA  MANAGEMENT  PROGRAMS 


(AFLC)  | 

AUTOMATED  TECH  ORDER  SYSTEM 

i 

PHASE  1: 

i 

•  DEVELOP  TECH  OROERS  IN  DIGITAL  FORMAT 

•  WORK  FROM  PAPER  TECH  OROERS 

•  DEMONSTRATIONS  WITH  F-16.  B  IB.  &  MX 

r 

i 

; 

! 

I 

| 

PHASE  II: 

j 

: 

•  WORK  FROM  DIGITIZED  TECH  OROERS 

•  DEPOT  MAINTENANCE  FIRST-FIELD  LATER 

| 
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KEY  RELATED  DATA  MANAGEMENT  PROGRAMS 


COMPUTER  BASED  MAINTENANCE  AIDS 


•  DEVELOP  SKILL  ADJUSTED  COMPUTER  DISPLAYS  FOR  MAINTENANCE  TECH 
OROERS 

•  PROVIDES  OATA  POOLS  AND  TRACKS  FOR  COLLATION 

•  B-1B  INTERMEDIATE  LEVEL  DEMONSTRATION  - 1984 
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AUTOMATION  OF  DESIGN  AND  TECHNICAL  DATA 

KEY  RELATED  DATA  MANAGEMENT  PROGRAMS 


MAINTENANCE  &  LOGISTICS  COMPUTER  AIDED  DESIGN 


(AFHRl) 

•  DEVELOP  METHOOS  TO  PUT  RELIABILITY  &  MAINTAINABILITY  INTO  DESIGN 
VIA  LESSONS  LEARNED 

•  EMPHASIS  ON: 

•  FAULT  ISOLATION  DURING  EARLY  DESIGN 

•  REDUCE  MAINTENANCE  REMOVE  I  REPLACE  TIME' 

•  USE  COMPUTERIZED  BIOMECHANICAL  MAN 

(AFAMRL) 


KEY  RELATED  DATA  MANAGEMENT  PROGRAMS 

(AFSC/ASD)  | 

INTEGRATED  DESIGN  SUPPORT  SYSTEM  1 

AN  EXECUTIVE  SOFTWARE  PROGRAM  TO:  | 

•  CAPTURE  AND  STORE  SELECTIVE  CAD  /  CAM  DATA  1 

•  PROVIDE  LOGISTICS  FEEDBACK  TO  DESIGNER  •  "LESSONS  LEARNED"  f 

•  CONTROL  CONFIGURATION  DATA  BASE  9 

•  MANAGE  OATA  BASE  INFORMATION  IN  A  CENTRALLY  CONTROLLED  1 

FILE  I 

•  TRANSFER  TO  AFLC  WITH  WEAPON  SYSTEM  9 
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AUTOMATION  OF  DESIGN  &  TECHNICAL  DATA 

KEY  RELATE0  DATA  MANAGEMENT  PROGRAMS 


(AFSl 

LOGISTICS  INFORMATION  MANAGEMENT  SUPPORT  SYSTEM 

•  KEY  TO  DIGITAL  LOGISTICS  MANAGEMENT 

•  INTEGRATE  EXISTING  ANO  PLANNED  DIGITAL  LOGISTICS  SYSTEMS 

•  OEVELOP  COMMUNICATION  NETWORK  FOR  LOGISTIC  INFORMATION 

•  LOG  C5  CONCEPT 

•  TO  BE  OPERATIONAL  PRIOR  TO  1990 


OUTLINE 


•  BACKGROUND 

•  ASSESSMENT  -  SAF/AL  CONCERNS 

•  PRELIMINARY  FINDINGS 

•  KEY  PROGRAMS  SYNOPSIS 

•  SUMMARY 


AUTOMATION  OF  DESIGN  AND  TECHNICAL  DATA 

SUMMARY 


•  AGREE  WITH  SAF/AL  -  AF  NEEDS  TO  THINK  ABOUT  HOW  TO 
EXPLOIT  TECHNOLOGY  THROUGHOUT  LIFE  CYCLE 

•  PROGRAM  CONTENT  AND  SCOPE  PROBABLY  NOT  ADEQUATE 
TO  EXPLOIT  TECHNOLOGY 


•  PROGRAMS  NOT  TIED  TOGETHER: 

•  SHOULD  BE 

•  NOT  SURE  HOW  FAR  TO  GO 

•  NON-TRIVIAL  QUESTIONS 


SUMMARY  *  ACTION  PUN 


ESTABLISH  AFSC I AFLC  EXECUTIVE  STEERING  GROUP 

i 

i 

•  INPUTS  FROM  USING  COMMANDS 

•  CLOSE  AUGNMENT  WITH  LIMSS 

j 

•  0  -  6  LEVEL  WORKING  GROUP  j 

i 

•  STATUS  REPORT  ON  ROADMAP  -  180  DAYS  i 

t 
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TECHNOLOGY  TRANSFER  TO  A  DUAL  SOURCE 


by 
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General  Dynamics  Convair  Division 
San  Diego,  California 


"SUMMARY" 


Technology  transfer  is  a  new  approach  to  second  source  procurements.  It 
requires  not  only  the  transfer  of  the  design  activity's  engineering  data  to  the 
new  source  but  also  the  information  on  why  the  design  turned  out  the  way  it 
did. 

This  paper  describes  the  challenges  to  the  configuration  and  data  managers  in 
establishing  baselines,  processing  of  changes,  and  identifying  the 
documentation  that  defines  the  “why”  behind  the  design.  It  identifies  the 
approaches  used,  the  lessons  learned,  and  the  remaining  problem  to  be  solved. 


Technology  Transfer  to  a  Dual  Source 


Technology  transfer  may  be  the  ultimate  in  alternate  source  procurement  action. 
It  provides  for  the  simultaneous  procurement  of  identical  items  from  dual 
sources.  It  provides  new  challenges  to  the  configuration  and  data  managers  of 
the  original  design  activity,  the  second  source,  and  the  procuring  activity. 

Many  of  you  in  the  audience  who  have  been  attending  these  ADPA  sessions  for  a 
while  are  already  thinking  "Here  we  go  again  with  another  sermon  on  making 
drawings  for  reprocurement.  This  is  just  going  to  be  another  re-hash  of  the 
MIL-D-1000  Category  E,  DOD-D-IOOO  level  3  discussion  all  over  again." 

If  you  ever  get  involved  in  a  technology  transfer  program  you'll  find,  like  I 
did,  that  this  type  of  program  involves  more  than  the  transfer  of  engineering 
drawings.  Your  attendance  at  this  type  of  meeting  indicates  to  me  that  you  are 
interested  in  producing  quality  documentation  and  there  probably  would  not  be 
any  problems  with  another  source  using  your  drawings. 

Going  into  this  program,  I  had  no  concerns  either.  My  company  had  always 
prided  itself  on  the  quality  of  its  drawings  and  the  delineation  they  provided. 
I  was  convinced  that  nobody  made  better  drawings  than  we  did  and  anybody  could 
produce  identical  products  from  our  drawings.  I  still  believe  this  but  I  now 
have  a  better  appreciation  of  the  problems  that  the  Government  faces  when  it 
attempts  to  second  source  Identical  item.  I  found  out  that  technology  transfer 
is  more  than  a  drawing  transfer. 

The  feature  that  makes  a  technology  transfer  program  different  from  other 
second  source  activity  is  that  in  addition  to  providing  the  design  definition 
of  how  the  item  is  to  be  made,  you  must  provide  the  information  on  why  it's 
designed  the  way  it  is.  In  other  words,  what  was  the  technology  that  made  the 
item  what  it  is  and  how  it  is.  It's  why  the  lines  and  notes  on  the  drawings 
and  the  requirements  in  the  specifications  are  what  they  are.  Technology 
transfer  is  the  transfusion  of  this  knowledge  from  the  original  design  activity 
to  the  second  source. 

You  can  begin  to  see  the  challenges  taking  form  but  let  me  add  two  other 
dimensions  to  them.  First,  there  was  the  challenge  that  keeps  all  of  our 
companies  in  business  -  profit.  The  financial  implications  of  the  technology 
transfer  I  was  involved  in  were  significant.  Secondly,  our  program  was  a  two 
way  transfer.  We  were  transferring  structural  technology  to  a  source  that  was 
transferring  electronics  technology  to  us. 

The  financial  implications  were  significant  not  only  because  they  involved  big 
dollar  amounts  but  because  the  company's  opportunity  to  compete  for  these 
dollars  was  directly  linked  to  its  ability  to  successfully  transfer  its 
technology  to  the  other  source.  If  you  were  unable  to  accomplish  the  transfer 
for  some  reason  within  your  control,  the  portion  of  the  second  source  pie  you 
could  compete  for  was  severely  reduced. 
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The  face  that  ic  was  a  two-way  transfer  helped  to  break  down  some  of  the 
natural  barriers  that  seem  to  arise  in  a  second  source  procurement.  I  think 
there  is  a  natural  resentment  when  your  product  is  selected  for  second 
sourcing.  You  perceive  it  as  a  threat  and  perhaps  you  are  reluctant  to  go  the 
extra  mile  it  takes  to  dig  out  an  answer  to  a  question  raised  by  the  second 
source.  With  the  two  way  transfer  you  react  to  a  question  of  request  from  the 
second  source  just  like  it  was  coming  from  your  own  company  because 
you  know  you're  going  to  be  making  your  own  request  of  the  other  contractor  and 
you're  going  to  expect  service  in  kind. 

The  challenges  to  the  configuration  manager  start  with  the  need  to  identify  and 
establish  a  product  baseline  as  a  departure  point  for  future  decisions  on 
changes.  We  recognized  that  this  would  probably  have  to  be  an  iterative 
process  in  order  to  capture  in-process  approved  changes  as  a  part  of  the 
baseline.  This  turned  out  to  be  true  with  one  important  exception.  We  didn't 
have  any  control  over  our  customer's  approval  of  Class  I  changes  that  had  been 
pending  in  his  house  for  approval.  Even  today,  we  have  to  re-evaluate 
baselines  because  the  customer  has  approved  a  Class  I  change.  Because  the  new 
source  has  not  gotten  far  enough  into  their  implementation  to  cause  an  impact , 
there  has  not  been  a  need  for  a  related  change  as  yet  but  I've  learned  a 
lesson.  The  next  time  I'll  require  a  review  of  all  pending  Class  I  changes  and 
the  submission  of  related  changes  by  the  second  source.  This  would  provide  the 
customer  an  identification  of  the  total  Impact  of  a  change  and  also  provide  a 
firm  effectlvity.  It  would  also  make  the  second  source  aware  of  pending 
changes  that  could  influence  some  of  his  decisions  in  setting  up  his  production 
facility. 

Having  established  a  baseline,  the  next  consideration  becomes  one  of  a  joint 
evaluation  of  future  changes  for  impact,  desirability  and  effectlvity.  Our 
decisions  on  how  to  best  obtain  the  required  information  from  the  second  source 
was  a  direct  approach.  We  simply  set  another  place  at  the  table.  We  made  the 
second  source's  representative  a  member  of  the  family  and  included  him  as  a 
member  of  our  change  evaluation  and  approval  boards.  At  the  beginning,  there 
was  a  reluctance  to  continue  the  honest  dialogue  necessary  for  a  good  change 
evaluation.  Having  the  competition  in  attendance  tended  to  stifle  the  open 
discussions  that  had  previously  occurred.  Gradually,  however,  the  realization 
sunk  in  that  we  couldn't  make  a  decision  on  our  own  change  Implementation 
without  this  open  discussion. 

Our  biggest  problem  with  changes,  however,  is  the  Class  II  change.  This 
problem  occurs  in  two  forms.  One  is  the  problem  of  a  change  that  is  Class  II 
to  us,  and  Class  I  to  the  second  source.  Since  we  want  to  maintain  the 
ldenticality  of  the  product ,  we  always  have  to  evaluate  the  problem  of  our 
implementation  versus  the  possiblity  that  the  procuring  activity  will 
disapprove  the  Class  I  change  from  the  second  source.  This  type  of  change  must 
be  evaluated  on  a  case-by-case  basis  weighing  the  merits  and  risks  associated 
with  each  proposed  change. 


At  our  stage  of  manufacture,  the  most  prevalent  case  is  the  situation  where 
manufacturing  requests  a  Class  II  change  that  will  make  their  job  easier  or 
cheaper.  From  an  engineering  viewpoint,  this  type  of  change  does  not  make  any 
technical  difference  so  the  effectlvity  of  the  change  is  established  to  be  at 
the  convenience  of  manufacturing.  Since  we're  well  into  production,  our  supply 
lines  are  well  stocked  and  change  implementation  may  not  be  convenient  or 


economical  until  some  number  of  downstream  manufacturing  lots.  With  the  second 
source  just  getting  ready  to  cut  chips,  he  may  want  to  plan  his  implementation 
of  the  change  to  be  effective  in  his  first  lot.  Although  we  can  all  agree  that 
it  would  be  foolish  for  him  to  plan  his  fabrication  for  a  few  vehicles  to  match 
our  configuration  and  then  make  the  change,  we're  faced  with  the  dilemma  that 
technically  the  change  doesn't  make  any  difference  while  still  recognizing  our 
requirement  to  have  both  manufacturers  produce  identical  configurations.  A 
further  complication  is  the  fact  that  we  have  the  DD250  responsiblity  for  the 
vehicles  produced  by  the  other  source  and  must  account  for  every  change 
implementation.  Any  of  you  who  have  ever  tried  to  track  the  actual  factory 
implementation  of  Class  11  changes  know  that  at  best  its  a  very  difficult  task. 
When  you're  dealing  with  another  manufacturing  source  the  difficulty  is 
compounded.  In  general,  we  have  agreed  with  the  second  source  to  have  him 
implement  the  change  on  his  first  vehicle  while  holding  our  own  most  convenient 
cut-in.  The  responsiblity  for  identifying  the  differences  between  our 
configuration  and  that  of  the  second  source  has  been  placed  on  the  second 
source.  As  we  prepare  for  a  selloff,  we  come  armed  with  the  list  of  changes 
that  we  had  cut-in  for  the  specific  manufacturing  lot  of  which  his  vehicle  is  a 
part.  Any  differences  from  this  list  must  be  justified  by  the  second  source. 
The  accepted  justification  for  the  differences  is  an  engineering  change  which 
allows  a  cut-in  at  manufacturing's  convenience.  Since  the  change  doesn't  make 
any  difference  technically  we  feel  we  have  fulfilled  our  commitment  to  produce 
identical  configurations.  Identifying  the  differences  in  configuration 
provides  us  the  backup  necessary  to  support  the  delivered  vehicles  during  depot 
maintenance . 

All  of  the  preceeding  discussion  viewed  the  configuration  management  problems 
from  the  design  activity's  perspective.  When  you're  on  the  receiving  end  of 
the  transfer,  the  problems  become  procedural  ones.  You’re  dealing  with  someone 
elses  drawings  and  change  paper.  You  find  that  information  your  people  are 
accustomed  to  receiving  is  not  provided  by  the  other  source  in  the  same  manner 
and  they  have  to  get  their  information  from  two  or  more  sources.  Your 
company's  standard  parts  and  processes  have  to  be  evaluated  against  the  parts 
and  processes  specified  by  the  other  design  activity.  Is  what  is  specified  the 
same  as  yours  with  a  different  identification  or  is  it  truly  different?  How  do 
you  minimize  the  turmoil  in  the  factory  and  procurement  departments  that  would 
be  caused  by  performing  the  same  process  or  stocking  the  same  part  or  material 
under  different  part  numbers?  All  of  these  become  the  problems  the 
configuration  manager  has  to  face  and  solve  in  a  technology  transfer  program. 

The  challenges  facing  the  data  manager  in  this  type  of  program  are  formidable. 
By  having  to  transfer  the  "why"  behind  the  product,  the  data  manager  must 
identify  and  track  down  a  veritable  mountain  of  paper.  Compiling  the  formal 
documentation  that  was  previously  prepared  and  submitted  due  to  CDRL 
requirements  is  a  comparatively  simple  procedure  when  you  maintain  a  contract 
data  depository  such  as  we  do.  Providing  this  data  becomes  a  matter  of 
extracting  the  proper  data  from  the  file  and  having  it  reproduced  for  shipment 
to  the  second  source.  The  informal  data  presented  another  set  of  problems. 

The  most  difficult  of  these  is  to  identify  what  data  exists.  How  many  of  the 
data  managers  in  the  audience  know  when  one  of  the  engineers  makes  a  stress 
calculation,  runs  a  development  test  or  conducts  a  tradeoff  of  design 
alternatives?  It  is  this  type  of  study,  analysis  and  test  that  represents  the 
technology  that  made  your  product  what  it  is.  It  is  why  your  design  turned  out 
the  way  it  did.  Much  of  this  information  is  not  available.  It  existed  in 
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someone's  head  aC  Che  moment  of  decision.  It  existed  on  the  desk  pad  until  the 
janitors  came  by  and  emptied  the  trash.  But  much  of  it  was  written  down;  in 
memos  to  the  boss  or  to  the  designer;  in  the  engineer's  notebook;  in  forms  too 
numerous  to  mention.  The  real  job  in  technology  transfer  is  to  identify  how 
much  of  this  type  of  data  exists  and  locate  it.  Since  we  can't  clone  the 
engineer  and  send  him  to  the  second  source,  the  best  we  can  hope  for  is  to  take 
his  documented  knowledge  and  transfer  it.  The  essence  of  technology  transfer 
is  to  provide  the  second  source  the  information  he  needs  to  make  the  same 
informed,  intelligent  decision  that  the  original  design  activity  would  make. 

The  data  doesn't  have  to  be  pretty;  it  just  has  to  be  usable.  And  to  be  usable 
it  must  be  available! 

This  same  problem  exists  without  a  technology  transfer  program.  Our  engineers 
are  a  mobile  population.  How  much  technology  can  be  or  will  be  transferred  to 
his  replacement  from  the  time  he  gives  his  two  week  notice?  The  challenge  to 
the  data  manager  is  what  kind  of  a  low  cost  program  can  be  implemented  to 
capture  and  catalogue  this  information?  How  can  you  let  your  company  take 
advantage  of  the  work  they  all  ready  paid  for  and  not  reinvent  the  wheel  as 
personnel  transfer  to  other  programs,  retire,  or  take  jobs  with  other 
companies? 

Maybe  the  personal  computer  in  the  office  will  make  the  solution  to  this 
problem  easier;  or  it  could  make  it  worse.  I  haven't  found  the  solution  to 
this  problem  but  I  hope  one  of  us  here  today  will.  When  you  do,  I  hope  you'll 
share  it  with  us  at  an  ADPA  meeting. 
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Abstract 

Tradition  within  the  design  documentation  groups  has  played 
a  very  important  role  in  the  structure  of  checking,  author¬ 
ization  and  release  of  engineering  drawings.  This  tradition 
has  evolved  from  the  need  to  communicate  design  authorization 
from  engineering  to  the  various  service  groups  such  as  manu¬ 
facturing  and  materiel.  The  computer,  with  its  impact  on 
design  and  manufacturing,  has  necessitated  a  new  approach  to 
prevent  unauthorized  access  to  the  design  information  on  the 
files.  At  the  same  time  the  new  method  must  communicate  the 
design  authenticity  to  all  affected  agencies. 

1.  INTRODUCTION 


The  engineering  process  has  always 
relied  upon  signatures  of  persons  in 
the  design  drawing  approval  cycle  to 
indicate  design  acceptance.  Drawings 
and  other  engineering  information  are 
new  being  created  and  stored  in  compu¬ 
ter  files.  These  files  can  be  acci¬ 
dentally  or  intentionally  altered  if 
adequate  safeguards  and  procedures 
have  not  been  developed.  The  purpose 
of  password  security,  combined  with 
programmer  coding,  can  effectively  pro¬ 


vide  the  controls  desired.  In  addition, 
this  method  will  permit  controlled  access 
to  interim  design  data  on  a  company  wide 
basis. 

2.  AUTHORIZATION  METHODOLOGY 
2.1  ENGINEERING  RELEASE 
Computer  Aided  Design  and  Computer  Aided 
Manufacturing  (CAD/CAM)  has  certain  char¬ 
acteristics  which  inhibit  the  traditional 
authorizing  approach  using  signatures. 

Two  factors  determine  that  a  need  to 
change  this  method  is  required  when  using 
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CAD/CAM.  First,  video  generated 
drawings  do  not  accept  a  true  signa¬ 
ture  readily.  In  essence  this  can  be 
done  but  it  is  unwarranted  because  of 
the  cost  and  the  elaborate  hardware 
systems  that  would  be  required. 

Second,  communication  of  CAD/CAM 
drawings  on  video  is  now  instantaneous 
and  these  can  be  made  available 
throughout  the  facility  in  any  state 
of  completion  or  authorization.  There¬ 
fore  file  protection  is  the  ultimate 
goal  of  such  a  control  system  and  we 
must  capitalize  on  the  positive  attri¬ 
butes  of  CAD/CAM  to  implement  a  satis¬ 
factory  protection  scheme. 

When  we  speak  of  file  protection  in 
this  paper  we  are  strictly  referring 
to  limiting  the  access  of  individuals 
to  the  design  documentation  residing 
on  computer  accessable  magnetic  files. 
Inherently  we  must  tie  file  protec¬ 
tion  to  signature  authority  in  order 
to  assure  that  the  drawing  review  pro¬ 
cess  has  taken  place.  In  turn  this 
means  that  file  protection  and  author¬ 
ization  are  synnonomous . 

Figure  1  pictorially  describes  a  sim¬ 
plified  drawing  generation  and  review 
process.  Normally  an  engineer  pre¬ 
pares  a  drawing (s)  which  he  signs  and 
gives  to  his  supervisor  for  review  and 
approval.  Once  completed  the  engineer 
obtains  several  "not  released"  repro¬ 


ductions  (prints).  He  now  delivers  the 
original  drawing  and  two  prints  to  the 
design  checker.  He  also  gives  one  copy 
to  each  organizational  entity  who  has 
been  designated  to  review  the  drawing (s) . 
Each  suggested  or  dictated  revision  is 
cycled  back  to  the  originating  engineer 
for  possible  change.  This  action  con- - 
tinues  until  all  of  the  discrepancies 
have  been  resolved.  In  the  manual  sys¬ 
tem  this  means  that  all  of  the  review 
organizations  have  "signed"  the  drawing (s) 
indicating  their  approval.  The  package 
is  now  ready  for  release. 

The  above  process  with  or  without  indi¬ 
vidual  company  modifications  to  this 
scheme  has  been  quite  successful.  The 
authorizing  method  that  will  now  be 
described  below  attempts  to  adopt  new 
computer  based  technology  with  an  old 
proven  method  of  doing  business. 

2.2  PASSWORD  CONTROL 

The  basic  premise  we  are  establishing  is 
the  privacy  of  a  password  as  used  to 
access  a  computer  system.  This  password 
is  treated  as  you  would  treat  the  key  to 
your  desk  or  the  combination  to  a  three 
tumbler  lock.  The  ultimate  responsi¬ 
bility  for  the  security  of  a  password 
must  reside  with  the  individual  himself. 

A  "key  to  the  computer  must  be  also 
treated  as  a  revokable  privilege.  To 
illustrate  the  use  of  a  password  in  a 
CAD/CAM  system,  it  would  be  advantageous 
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to  use  che  checker  and  engineering 
functions  as  an  example. 

Assume  that  an  engineer  and  a  checker 
is  assigned  to  a  new  design  program. 

At  this  time  they  are  given  passwords 
known  only  to  themselves  and  the 
issuing  agency.  An  organization  which, 
is  interested  in  cost  collection  by 
computer  costs  will  also  issue  a  list 
of  cost  account  numbers.  These  num¬ 
bers,  applied  to  a  specific  task, 
will  permit  the  required  analyses 
described  above. 


The  list  below  shows  a  typical  list  of 
account  numbers  and  passwords.  Such  num¬ 
bers,  or  combination  of  numbers  and 
letters,  are  determined  to  be  valid  by 
the  computer  program  and  programmed  for 
the  statistical  tasks  to  be  performed. 

PASSWORDS 

12A94Z 

STARWARS 

GEMINI 

ALPHA6 


ACCOUNT  NUMBERS 

A9-1092-6100  WING 

42-6A91-4132  FUSELAGE 

L8-123A-4667  TANK 

BC-H672-19  ACTUATOR 

Now  back  to  the  engineer  and  the 
checker . 

The  engineer  wishes  to  begin  a  design. 
He  logs  onto  the  CAD/CAM  system  in  a 
prescribed  manner  and  includes  an 
account  number  associated  with,  his 
task  and  a  password  which  opens  the 
system  to  him.  Next  he  performs  his 
design  effort  and  routinely  files  the 
drawing  away  in  the  magnetic  medium 
used  on  his  system.  Each  design 
session  is  treated  in  this  manner  so 
that  the  drawing  is  available  for 
viewing  by  anyone  so  authorized — but, 
that  person  can  only  read — not  write 
on  that  drawing.  His  password  will 
not  permit  design  access  to  another 
person's  drawing. 

When  the  design  engineer  has  finished 
his  task,  he  types  onto  the  drawing 
his  name  in  the  space  reserved  for  the 
designer.  Next  he  notifies  his  super¬ 
visor  the  drawing  is  ready  for  review. 
The  design  supervisor  logs  onto  the 
CAD/CAM  system  (.with  his  account 
number  and  password)  and  types  his 
name  into  the  appropriate  authoriza¬ 
tion  block.  Both  pieces  of  signature 


data  are  dutifully  recorded  on  a  log 
tape  for  possible  audit.  We  must  remem¬ 
ber  only  that  particular  password  will 
permit  typing  that  particular  "signa¬ 
ture"  name. 

At  this  point  in  time  the  drawing  is 
passed  to  the  checker  for  review  and 
check.  He  will  log  onto  the  system  in 
precisely  the  same  manner  as  above  but 
the  checker's  password  and  account  num¬ 
ber  is  different.  For  approval  indica¬ 
tion,  the  checker  will  type  his  name 
into  the  system.  Now  the  drawing  is 
sent  to  data  control  for  release.  The 
typical  log-on  screen  described  above 
is  shown  on  Figure  2. 

Obviously  all  review  and  approval  agen¬ 
cies  such  as  reliability,  maintain¬ 
ability,  etc.,  use  the  same  method  as 
that  described  above.  If  circumstances 
occur  that  require  expediting  when  some¬ 
one  (eg.  checker)  is  not  available  the 
CCB  Chairman  or  Program  Manager  (or  who¬ 
ever)  can  be  given  a  universal  password 
for  authorization  to  release  (his  name) 
in  lieu  of  any  others.  These  actions  are 
also  generated  on  the  log  tape  for  recor¬ 
dation  and  audit. 


Figure  2  CADAM  SCREEN 


3.  ECONOMICS 

The  information  flow  previously 
described  hai  ebvious  cost  savings. 

Most  of  these  are  "soft"  savings  which 
revolve  around  better  communication, 
increased  accuracy,  shorter  turn¬ 
around  times  and  integration  with  other 
automated  systems.  One  very  large 
"hard"  savings  which  is  usually  over¬ 
looked  or  ignored  is  white  print  repro¬ 
duction  and  microfilming  costs.  Nor¬ 
mally  an  industry  is  extremely 
sensitive  to  record  retention  and  dis¬ 
tribution  of  information.  If  an 
organization  has  completed  a  design, 
that  organization  will  send  that  design 
to  the  various  support  groups  (includ¬ 
ing  check)  for  evaluation,  confirma¬ 
tion  of  design  accuracy  and  information. 
For  "arguments  sake"  lets  assume  the 
following  support  groups  are  involved 
in  the  design  process.  These  include, 
at  a  minimum,  manufacturing,  materiel, 
tooling,  safety,  reliability,  check, 
producability  and  various  history 
files.  This  distribution  list  could 
be  about  10  prints.  Typically  a  dis¬ 
tribution  list  is  about  20  prints  on 
a  major  project.  At  50c  (an  arbibrary 
value)  for  an  "E"  size  drawing  we 
would  expend  $10.00  for  the  initial 
"waterfall"  process. 

Of  course  it  is  a  rare  occasion  that 
this  is  a  final  distribution.  By  the 


time  an  approved  release  of  that  drawing 
has  been  made  we  have  expended  about 
$25.00  for  one  original  drawing.  Next 
comes  the  inevitable  microfilming  pro¬ 
cess  and  the  attendant  aperture  cards. 
Generally  you  can  add  another  $15.00 
to  the  original  costs.  Basically  from 
our  investigations  on  average  situations, 
we  have  found  that  the  reproduction  costs 
(including  microfilming)  for  an  "E"  size 
drawing  range  between  $25.00  and  $75.00 
depending  upon  the  number  of  iterations 
and  the  length  of  the  distribution  list. 
Obviously  the  end  of  this  cost  is  still 
not  in  sight.  Next  comes  the  inevitable 
change  process  which  adds  to  the  repro¬ 
duction  costs;  more  microfilming; 
delivery  of  microfilm  to  the  customer 
and  the  ultimate  archive  storage. 

Much  of  these  reproduction  costs  can  be 
avoided  using  the  video  terminal  as  the 
"paper"  for  the  approval  cycle  and 
change  process.  Complete  elimination 
of  all  paper  is  an  impossibility  but  an 
80%  reduction  is  a  feasible  goal .  Cer¬ 
tainly  this  discussion  is  over  simpli¬ 
fied  but  it  does  point  to  a  direction 
we  can  take  in  the  future  to  solve  many 
age-old  problems  known  to  all  of  us. 

4.  SUMMARY 

The  system  described  is  basic  and  effec¬ 
tive.  Greater  sophistication  can  be 
developed  if  required.  For  example,  the 
checker  has  an  organizational  number. 


N-5 


I 


During  the  log-on  process  this  number 
can  be  compared  with  his  password 
employee  number.  If  everything  matches, 
his  department  or  work  group  can  be  the 
only  persons  able  to  access  the  spe¬ 
cific  checker's  signature  area.  Cer¬ 
tainly  even  more  complex  schemes  can 
be  envisioned. 

The  advantages  of  CAD/CAM  and  signa¬ 
ture  authorization  are  multi-fold. 

First  and  foremost  is  the  instant  com¬ 
munication  of  a  design  throughout  the 
product  system.  The  drawing  can  be 
offered  during  the  course  of  design 
and  status  of  that  drawing  is  imme¬ 
diately  obtained. 

Additionally,  "soft"  savings  are 
going  to  be  part  of  system  espe¬ 
cially  when  turn-around  times  are 
considered.  Reproduction  costs  will 
drop  dramatically  and  the  associated 
savings  will  effectively  bring  the 
total  release  system  costs  down.  Not 
all  problems  can  be  resolved  using 
this  systems  approach,  but  where  used, 
design  communications  will  be  vastly 
improved . 
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A  TAXONOMY  FOR  SOFTWARE 


1.  INTRODUCTION 


Software  at  Hughes  is  used  in  many  ways:  as  a  part  of  the 
products  we  sell;  as  aids  in  engineering  and  management  of  pro¬ 
duct  developnent;  in  manufacturing  and  test  of  products;  and  as 
part  of  the  broad-based  automated  management  and  information  sys¬ 
tems  used  to  run  the  enterprise.  The  use  is  diverse  and  per¬ 
vasive.  The  software  is  not  all  the  same  nor  are  the  require¬ 
ments  for  the  management  of  the  software  the  same. 

This  paper  defines  five  broad  uses  of  software  along  with 
some  important  management  considerations.  It  is  written  to  clar¬ 
ify  some  of  the  confusion  created  by  indiscriminate  use  of  the 
term  software  when  the  speaker  is  refering  to  one  use  and  the 
listener  is  thinking  about  another  use.  It  also  points  out  some 
management  considerations  that  are  appropriate  to  some  kinds  of 
software  but  not  to  all.  It  also  coirments  on  the  different  views 
of  software  quality  appropriate  to  the  various  kinds  of  applica¬ 
tions.  The  five  uses  of  software  are  described  in  terms  of: 

Mission  critical  programs 
Direct  support  software 
Engineering  software 
Administrative  software 
Personal  software 


2.  MISSION  CRITICAL  PROGRAMS 

These  programs  are  used  to  provide  the  essential  functional 
capability  used  in  the  digital  processors  in  the  systems 
delivered  to  the  customer.  Sometimes  they  are  delivered  as 
operational  programs  in  the  form  of  software  and  sometimes  they 
are  embedded  in  the  form  of  firmware  as  part  of  the  hardware. 
Typical  terms  used  to  describe  these  programs  are  "Operational 
software",  "Built-In  Test"  programs,  "Firmware",  "Embedded  Com¬ 
puter  Software",  "Tactical  Logic",  "Control  Programs",  "Applica¬ 
tion  Programs",  etc.  Examples  of  application  programs  developed 
by  Hjghes  include  tracking  programs,  guidance  programs,  naviga¬ 
tion  programs,  display  programs,  detection  programs.  Applica¬ 
tions  to  missile  systems  and  autonomous  vehicle  operations  are 
another  example  of  special  interest  as  the  software  operates 
autonomously  and  can  be  lethal. 
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2.1  Definition 


Mission  critical  programs  are  essential  for  the  system  to 
perform  correctly.  Without  them  one  or  more  of  the  essential 
functions  of  the  system  would  be  inoperative. 


2.2  Usage 


Mission  critical  programs  are  dedicated  to  the  operation  of 
the  system  product  that  is  acquired  by  a  customer.  They  provide 
the  broad  functional  capability  of  the  product.  The  functional 
requirements  of  these  programs  are  tied  ultimately  to  the  system 
performance  requirements,  either  as  a  software  requirement  placed 
on  the  data  processing  elements  or  indirectly  as  a  "black  box" 
performance  requirement  to  be  implemented  as  programmed  digital 
logic.  The  engineering  of  these  programs  is  a  part  of  the 
overall  engineering  of  the  Hughes  deliverable  product,  closely 
tied  to  the  mission  of  the  embedded  computer  system  and/or  the 
functional  performance  of  the  product. 

Computer  programs  may  be  delivered  as  software  (executed  out 
of  RAMs)  or  firmware  (executed  out  of  ROMs) .  Engineering  of  the 
programs  is  the  same  -  using  the  same  forms  of  docunentation  and 
reviews.  Configuration  management  practices  are  the  same  for  the 
engineering  phase,  differing  only  in  that  the  RCMs  are  treated  as 
hardware  items  after  they  are  baselined  by  burn-in  or  other  tech¬ 
nique  applicable  to  the  particular  type  of  ROM. 


2.3  Management  Concerns 

Software  intensive  firmware  should  be  engineered  and  managed 
as  software  but  often  it  engineered  and  documented  as  hardware. 
Software  engineering  techniques  are  used  for  software  intensive 
firmware  applications  where  sequences  of  instructions  execute  in 
a  processor  and  the  logic  is  not  apparent  from  an  examination  of 
a  memory  map.  Hardware  intensive  firmware  (small,  non-complex 
forms  of  digital  logic)  and  data  forms  (for  example,  programmed 
logic  arrays)  are  engineered  and  documented  as  hardware. 

Mission  critical  software  engineering  standards  are  often 
isolated  from  the  general  engineering  standards  and  procedures. 
For  example,  a  system  preliminary  design  review  often  isolates 
the  software  review  from  the  systems  and  hardware  design  review 
even  though  the  software  provides  the  functional  capability  of 
the  system.  The  general  Company  engineering  directives  should  be 
applicable  to  software  but  often  are  not  applied.  There  is  a 
tendency  to  write  a  separate  but  parallel  set  of  software  stan¬ 
dards  (sometimes  to  meet  the  implied  desires  of  the  customer) . 
The  policy  is  to  write  separate  standards  only  where  needed. 
Where  differences  occur,  software  engineering  practices  are 
defined  to  cover  the  differences,  such  as  in  configuration 


P-2 


l 


management,  quality  reviews,  etc. 


There  is  a  growing  pressure  in  the  customer  community  to 
define  software  development  processes  independently  from  the  gen¬ 
eral  system  engineering  process.  This  leads  to  isolation  of  the 
software  generation  process  from  the  general  engineering  of  the 
systems  product.  This  is  undesirable  because  the  programs  are  a 
part  of  the  product  and  the  engineering  process  cannot  be  arbi¬ 
trarily  split. 

All  software  embedded  in  Hughes  products  must  be  subject  to 
the  same  minimum  acquisition  standards,  documentation  standards 
and  review  standards.  Customer  standards  are  inadequate  for 
tailoring  to  the  different  project  levels  of  complexity.  A 
management  concern  is  that  there  is  no  well  defined  minimum 
acceptable  standard  that  can  be  tailored  and  applied  to  all 
acquisitions.  Mission  critical  programs  that  are  subcontracted 
are  subject  to  the  same  quality,  configuration  management  and 
testing  standards  as  are  internally  developed  programs.  Vendor 
proprietary  programs  and  GFI  embedded  in  products  are  subject  to 
acceptance  test  and  configuration  management  as  part  of  the  pro¬ 
duct. 


2.4  Quality  Issues 

The  customer's  definition  of  quality  focuses  on  conformance 
to  contractual  requirements  for  the  management  of  the  software 
engineering  process.  Issues  such  as  reviews  of  design  at  desig¬ 
nated  milestones,  plans  for  testing  and  management  of  the  confi¬ 
guration,  conformance  to  predefined  docimentation  standards,  and 
adherence  to  programing  standards  and  procedures  are.  major  con¬ 
cerns. 

Engineering  quality  is  concerned  with  the  identification  and 
incorporation  of  those  performance  attributes  that  best  represent 
the  customer's  interest.  Since  software  provides  much  of  the 
functional  capability  of  the  system  that  the  customer  sees, 
software  quality  attributes  need  to  be  defined  as  requirements  to 
be  incorporated  in  the  software  design.  Customer  definitions  of 
reliability,  maintainability,  transportability,  etc.,  need  to  be 
defined  as  part  of  requirements  for  incorporation  in  the  design. 


3.  DIRECT  SUPPORT  SOFTOARE 


This  software  is  used  directly  in  the  development  and  test 
of  the  company  products.  This  type  of  software  also  includes 
software  used  in  maintenance  of  the  product  (both  hardware  and 
software) .  Typical  software  considered  here  is  compilers, 
testware,  acceptance  test  programs,  hardware  test  programs. 
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utility  programs,  test  generator  programs,  loaders,  automatic 
test  equipment  (ATE)  software,  site  registration  programs,  link 
editors,  fault  location  programs,  and  system  calibration  pro¬ 
grams.  Off-line  exercise  evaluation  programs,  recording  pro¬ 
grams,  and  training  programs  are  other  examples  of  direct  support 
software.  The  computer  aided  test  (CAT)  software  used  in  accep¬ 
tance  of  hardware  is  an  example  of  direct  support  software  used 
for  hardware.  The  software  used  in  operation  of  production 
hardware  in  the  factory  (the  computer  aided  manufacturing  or  CAM) 
also  falls  into  this  use  category.  An  example  program  here  is 
the  APT  software. 


3.1  Definition 


Direct  support  software  is  software  necessary  for  the 
development  and  maintenance  of  hardware  and  other  software. 
There  is  a  direct  relationship  to  the  product  such  that  an  error 
in  the  support  program  can  cause  or  allow  an  error  or  fault  to 
enter  into  or  to  continue  to  exist  in  the  deliverable  product. 


3. 2  Usage 

Direct  support  software  is  needed  in  the  development  and 
maintenance  of  a  system  but  not  essential  for  performance  of 
critical  mission  functions.  It  is  used  in  implementation  and 
test  of  hardware  as  well  as  software  and  quite  often  is  delivered 
to  the  customer  as  a  part  of  the  system.  Direct  support  software 
includes  firmware  generation  systems  as  well  as  software  develop¬ 
ment  environments. 

Direct  support  software  is  increasingly  used  in  the  manufac¬ 
ture  and  test  of  hardware  as  automation,  including  CAM  and  CAT, 
is  applied  to  increase  factory  productivity. 

It  should  be  noted  that  there  is  a  difference  between  data 
and  programs  with  respect  to  how  they  are  managed  even  though 
software  is  often  defined  to  include  both  programs  and  data.  For 
example,  the  tape  containing  a  numerical  control  program  for  an 
automated  machine  on  the  factory  floor  is  "data"  and  is  managed 
in  the  same  manner  as  any  drawring.  The  program  used  to  generate 
the  numerical  control  tape  is  managed  as  software.  A  data  tape 
is  changed  by  an  engineering  activity  defining  new  hardware 
parameters  or  test  points.  A  program  is  changed  by  software 
engineers  modifying  the  logic  of  the  program. 


3. 3  Management  Concerns 


Direct  support  software  that  is  not  made  deliverable  by  con¬ 
tract  is  often  given  less  management  attention.  The  importance 
of  this  type  of  software  to  the  quality  of  the  products  makes  it 
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necessary  for  management  to  pay  attention  to  all  of  the  direct 
support  software  used  by  projects,  particularly  if  the  software 
is  to  be  used  on  more  than  one  project. 

Change  control  in  direct  support  software  should  be  tied  to 
ctenges  in  the  product  it  supports.  A  change  in  the  hardware  of 
the  system  product  must  consider  its  impact  on  the  supporting 
software  as  well  as  potential  impact  on  mission  critical  pro¬ 
grams.  Likewise,  a  change  in  the  programs  used  in  direct  support 
must  consider  impact  on  product  hardware,  both  current  production 
and  past  configurations  for  which  maintenance  responsibility 
still  exists. 

There  also  is  a  strong  feeling  in  the  customer  comnunity 
that  all  software  used  in  the  development  of  computer  programs  be 
made  available  as  a  part  of  the  contract,  whether  specifically 
developed  on  contractual  funds  or  otherwise.  The  engineering 
software  used  in  the  design  of  products  is  not  all  direct  sup¬ 
port,  and  not  necessary  in  a  turnkey  system.  Proprietary  tooling 
should  not  be  treated  as  direct  support  software.  This  is  a  con¬ 
tractual  issue  that  management  must  be  aware  of  during  negotia¬ 
tion  of  the  statement  of  work. 

Sometimes  direct  support  software  is  made  GFI  (as  in  the 
case  of  the  MTASS  or  the  CMS  2  compiler)  and  the  requirement  is 
to  maintain  the  configuration  without  making  unapproved  changes. 

Much  of  the  software  used  in  manufacturing  and  tools  used  in 
software  development  are  acquired  by  purchase  from  vendors. 
Since  the  engineering  of  this  software  is  not  open  to  inspection, 
then  the  acceptability  of  the  software  tool  is  by 
verification/validation  of  the  resulting  product.  In  such  case, 
the  management  requirement  is  to  maintain  configuration  of  the 
software  tools  as  certified  by  testing  of  the  product.  Changes 
made  to  the  software  must  be  demonstrated  to  have  no  negative 
impact  on  the  product. 


3.4  Quality  Issues 

In  general,  the  engineering  quality  attributes  of  efficiency 
of  performance,  robustness,  and  usability  are  not  as  important  as 
transportability  and  maintainability  for  this  class  of  software. 
The  management  aspects  of  software  engineering  process  is  not 
monitored  as  closely  as  the  management  of  the  mission  critical 
software.  In  testing,  more  weight  is  allocated  to  certification 
of  the  software  package  by  demonstrating  that  it  produces  the 
desired  product  than  by  in-process  reviews  and  independent  test¬ 
ing  of  the  software  package. 
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4.  ENGINEERING  SOFTWARE 


An  interesting  set  of  software  that  is  gaining  importance 
within  the  company  is  the  software  used  to  support  design  activi¬ 
ties.  Collectively  known  as  Computer  Aided  Design  (CAD)  systems 
and  Computer  Aided  Engineering  (CAE)  systems,  this  software 
includes  a  host  of  different  kinds  of  programs  used  in  the 
engineering  of  a  product.  Most  CAD  tooling  has  been  focused  on 
hardware  design  and  represents  a  very  heavy  investment  in  graph¬ 
ics  capabilities,  simulation  capability,  design  data  bases  and 
special  engineering  programs.  Examples  of  circuit  analysis  pro¬ 
grams  are  TEGAS,  DRC,  SUPER  CCMPACT,  and  SPICE.  Examples  of 
simulation  software  are  SIMSCRIPT,  SLAM,  MIMIC,  AISIM,  DAS/DDPM. 
Software  tooling  for  aid  in  systems  engineering  and  design  such 
as  SYSREM,  HERCULES,  SREM,  CAD6AT,  AIDES,  ISDOS,  AISIM,  and  RXVP 
are  examples  of  these  applications.  All  are  sophisticated 
software  programs  designed  to  aid  the  engineer  in  his  tasks. 


4.1  Definition 


Engineering  software  is  a  set  of  programs  used  to  improv 
the  productivity  of  the  engineering  process  or  quality  of  th. 
product. 


4.2  Usage 

Engineering  software  allows  individuals  to  augment  their 
work  with  the  capabilities  of  the  computer,  either  as 
simulation/modeling,  using  graphic  design  aides,  building  data 
bases  that  allow  individuals  to  interact  in  a  disciplined  manner 
or  as  comnunication  and  documentation  aides.  These  software 
packages  are  sometimes  large,  complex  systems  that  require  care¬ 
ful  tuning  for  optimal  usage  and  constant  change  as  they  adapt  to 
different  processing  environments  and  undergo  evolutionary 
growrth. 

The  trend  now  is  to  combine  them  into  a  system  with  an 
engineering  data  base  that  allows  an  engineer  to  perform  his  work 
at  an  automated  work  station.  The  common  characteristic  of  these 
programs  is  that  they  increase  the  productivity  of  the  individu¬ 
als  using  the  system.  Engineering  software  is  used  in  the  design 
of  a  product  but  not  directly  as  a  part  of  the  implementation  or 
manufacturing  and  maintenance  process. 

The  general  interest  in  this  category  of  software  by  our 
customer  community  and  industry  in  general  is  evidenced  by  the 
corrmitment  of  DoD  to  the  the  software  initiatives  as  evidenced  in 
the  STARS  program  and  the  sustained  efforts  towards  systematic 
introduction  of  Ada  along  with  its  programming  support  environ¬ 
ment  (APSE) . 


4.3  Management  Concerns 

There  is  a  tendency  to  make  the  software  tooling  that  is 
associated  with  a  product  deliverable  to  the  customer  in  a  turn¬ 
key  system.  This  is  acceptable  for  direct  support  software  as 
that  type  is  necessary  for  maintenance  but  not  acceptable  for 
engineering  software  which  gives  us  a  competitive  edge.  An  exam¬ 
ple  of  this  problem  is  faced  in  VHSIC  which  makes  the  DAST 
software  accessible  to  other  industries. 

Of  even  greater  concern  is  recent  customer  insistence  that 
vie  can  only  use  deliverable  support. software  in  the  engineering 
design  and  development  of  operational  software,  meaning  that  we 
cannot  use  effective  design  tools  unless  we  give  them  to  the  cus¬ 
tomer!  The  issue  of  proprietary  support  software  arose  in  the 
review  of  the  STARS  and  it  is  evident  that  there  is  general 
industry  concern  on  this  issue. 

Engineering  so-ftware,  and  to  some  extent  direct  support 
software,  represents  a  very  large  investment  in  computer 
resources  on  the  Fart  of  the  company.  There  is  a  concern  about 
the  investment  in  the  development  of  these  programs  and  more  con¬ 
cern  about  the  added  cost  for  maintenance. 


4.4  Quality  Issues 

A  basic  quality  issue  is  the  assurance  that  engineering 
software  is  maintainable  as  it  will  be  extended  many  times  during 
its  life  cycle.  It  should  have  a  user  friendly  interface  to  pro¬ 
mote  effective  use  by  engineering  personnel.  Engineering 
software  is  maintained  under  Company  configuration  management  in 
order  to  protect  the  high  capital  investment. 


5.  ADMINISTRATIVE  SOFIVIARE 

These  programs  are  used  in  the  general 
management/administration  activities  associated  with  company 
operations,  in  the  management  of  the  engineering  process,  and  in 
the  management  of  the  manufacturing  process.  They  include  the 
traditional  automated  data  processing  applications  of  payroll, 
inventory  control  systems,  marketing,  parts  management  systems, 
scheduling  systems,  manufacturing  control  systems,  and  pricing 
packages.  They  also  include  the  growing  number  of  applications 
found  under  the  general  name  of  Office  Automation.  Internal  com¬ 
munication  programs  and  other  systems  used  in  the  general  manage¬ 
ment  of  the  company  and  the  projects  fall  in  this  category. 
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5.1  Definition 


Administrative  software  is  software  used  in  the  control  of 
company  administrative  operations  and  management  of  the  engineer¬ 
ing  process  and  manufacturing  operations. 


5.2  Usage 

The  programs  in  this  category  are  most  often  thought  of  as 
business  programs  or  commercial  programs.  In  reality,  the  distin¬ 
guishing  feature  is  the  kind  of  information  or  data  base  that 
they  process.  The  data  base  for  administrative  programs  contains 
information  relevant  to  the  management  of  several  or  all  projects 
and  to  the  activities  of  the  company  in  general.  Engineering 
software,  on  the  other  hand,  contains  information  relating  to  the 
technical  process  used  in  creating  the  products  for  customer  use. 


5. 3  Management  Concerns 

The  information  in  the  administrative  data  base  reflects  the 
activities  of  the  company  over  a  period  of  years  and  is  of  great 
importance  to  the  continued  operation  of  the  enterprise.  As 
such,  it  is  often  sensitive  and  needs  to  be  protected  from 
accidental  change  or  access  by  unauthorized  personnel.  Manage¬ 
ment  of  the  data  base  requires  the  highest  expertise. 

There  is  some  confusion  in  management  between  engineering 
software  and  the  administrative  software  since  they  have  tradi¬ 
tionally  been  run  on  the  same  hardware  -  the  maxi  system  or  the 
large  mainframes.  With  the  growth  of  the  micro-mini  systems  and. 
the  lowering  cost  of  the  hardware,  basis  for  this  confusion  no 
longer  exists.  Engineering  software,  by  its  nature,  is  con¬ 
trolled  by  engineering  management.  Data  processing  management 
recognizes  this  difference  in  the  definition  of  the  two 
categories  of  administrative  software: 

•  Production  Software  -  that  software  used  in  production  for 
specific  application  and  is  managed  by  a  computing  depart¬ 
ment  or  center. 

*  Open  Shop  Software  -  that  software  used  for  an  application 
and  is  managed  and  run  by  the  end  user. 


With  the  explosive  growth  in  use  of  software  by  the  many  new 
and  expanding  applications,  there  is  a  constant  demand  for  more 
computing  resources.  This  continual  growth  in  demand  for  ser¬ 
vices  must  be  constantly  reviewed. 
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Hie  development  of  new  administrative  applications  is  not  as 
frequent  as  new  applications  are  created  for  engineering  software 
or  mission  critical  programs  embedded  in  new  products.  The  pri¬ 
mary  quality  attribute  is  maintainability,  to  meet  changing 
demands  of  the  users  and  new  hardware  additions.  There  is  a  need 
for  assurance  of  internal  configuration  control. 


6.  PERSONAL  SOPIVJARE 


These  programs  are  used  to  solve  the  unique  problems  that 
occur  in  everyday  work.  The  problems  that  they  solve  are  related 
to  the  needs  of  the  individual  using  the  software  and  not  incor¬ 
porated  into  deliverable  products  or  used  repeatedly  by  many 
other  users.  An  example  is  an  analytic  program  prepared  by  an 
engineer  in  identifying  the  side  lobe  patterns  of  a  radar 
antenna.  Another  example  is  an  information  data  base  kept  by  a 
manager  to  review  the  salary  scales  of  his  people. 


6.1  Definition 


Personal  software  are  application  programs  written  to  solve 
a  specific  problem  and  are  not  for  general  use  by  others. 


6. 2  Usage 

This  type  of  software  is  written  by  anyone  and  everyone. 
The  standards  applied  to  the  development  of  software  for  mission 
critical  programs,  direct  support  software,  engineering  software, 
and  administrative  software  are  not  necessarily  applied  to  per¬ 
sonal  software.  These  programs  are  those  typically  written  on 
personal  computers. 

The  basic  difference  between  personal  software  and  the 
software  found  in  other  uses  is  that  professional  engineering 
techniques  are  applied  in  the  specification  of  requirements 
(statement  of  user's  needs)  and  in  the  testing,  documentation  and 
packaging  of  the  software  for  prolonged  and  extensive  use  by 
other  than  the  developers  of  the  software.  The  process  of  detail 
design,  coding  and  debugging  are  generally  the  same  in  personal 
software  development  as  in  professionally  engineered  software. 


6.3  Management  Concerns 


Personal  programming  can  be  accomplished  by  using  profes¬ 
sional  software  engineering  techniques  as  well  as  amateur 


programming  practices  but  administrative  software,  engineering 
software,  mission  critical  programs  and  direct  support  software 
delivered  to  our  customers  require  professional  expertise. 

This  distinction  is  not  well  appreciated  by  non-professional 
software  developers. 

Hughes  cannot  allow  software  that  is  not  developed  to  pro¬ 
fessional  standards  to  be  used  directly  in  the  generation  of  pro¬ 
ducts  or  to  be  delivered  to  a  customer.  Highes  can  ill  afford 
the  extra  cost  of  software  generated  in  an  undisciplined  manner 
to  be  mingled  with  engineering  software  or  the  administrative 
software. 

The  problem  of  product  degradation  by  mingling  of  different 
categories  of  software  is  aggrevated  by  the  advent  of  engineering 
workstations.  The  software  used  here  wall  be  thought  of  as  "per¬ 
sonal"  by  the  user  and  thus  under  his  control.  The  mingling  of 
personal  programs  not  developed  to  standard  with  engineering 
software  and  company  products  must  be  avoided 

Personal  programming  is  useful  and  can  increase  individual 
productivity.  A  basic  issue  is  one  of  preventing  the  mixing  of 
the  personal  We  need  to  provide  for  its  effective  use  and  yet 
exercise  restrains  on  the  changes  to  controlled  software. 


6.4  Quality  Issues 

A  program  that  "works"  is  a  "good"  program  for  use  as  per¬ 
sonal  software.  This  criteria  of  acceptability  is  not  sufficient 
for  other  kinds  of  software.  Individual  creativity  used  in  a 
program  is  a  highly  praised  quality  attribute. 
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TYPES  OF  SOFTWARE 
A  Taxonomy  Based  Cn  Use 


The  following  taxonomy  of  software  is  based  several  different 
factors  but  generally  reflects  the  uses  defined  in  this  ID C. 

1.  MISSION  CRITICAL  PROGRAMS 


1.  Operational  programs  -  The  application  programs  that 
provides  the  major  functional  capability  of  the  system. 
Usually  is  delivered  in  the  form  of  software  but  in 
more  mature  systems  can  easily  migrate  into  firmware. 
Basic  criteria  is  that  the  requirements  for  the  pro¬ 
grams  decompose  from  system  functional  requirements. 
Customer  has  direct  input  into  the  statement  of 
requirements  and  in  the  acceptance  of  the  programs.  An 
example  is  a  command  control  communication  program. 

2.  Run-time  Support  Software  -  The  programs  needed  to  sup¬ 
port  hardware  interfaces,  handler  routines  and  operat¬ 
ing  system  functions.  Requirements  are  derived  from 
performance  requirements  placed  on  the  total  system, 
not  necessarily  the  functional  requirements  of  the  sys¬ 
tem.  The  customer  rarely  specifies  these  functional 
requirements  for  these  programs.  Implementation  can  be 
in  firmware  or  software.  Examples  are  the  on-line 
fault  detection  programs,  operating  systems  or  execu¬ 
tive  programs. 

3.  Hardware  Support  Programs  -  These  programs  provide  the 
digital  logic  that  one  would  have  found  in  analog  cir¬ 
cuitry  a  few  years  ago.  The  requirements  stem  from  the 
design  requirements  allocated  to  the  "black  box",  not 
from  the  system  functional  requirements.  Implementa¬ 
tion  is  most  often  in  firmware  but  the  logic  is  exten¬ 
sive  enough  that  the  technical  disciplines  of  software 
engineering  need  to  be  applied  for  management  of  the 
engineering  and  the  maintenance  of  the  product.  The 
programs  can  easily  migrate  into  VLSI  hardware.  An 
example  is  a  correlation  program. 

NOTE 

Hardware  intensive  firmware  is  not  considered  a 
part  of  mission  critical  software. 
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DIRECT  SUPPORT  SOFTV&RE 


1.  Programing  Support  Environment  -  The  software  used  in 
the  generation  and  maintenance  of  other  software,  such 
as  compilers,  utility  software,  loaders,  configuration 
management  software,  editors,  etc.,  used  in  the  genera¬ 
tion  and  maintenance  of  code.  Programing  systems  used 
for  firmware  are  a  part  of  the  support  environment. 
Requirements  are  not  derived  from  system  functional 
requirements  but  from  the  need  to  generate  and  maintain 
software  in  a  cost  effective  manner.  Implemented  in 
software  and  generally  run  in  a  host  environment.  Cus¬ 
tomer  is  primarily  concerned  with  standardization  of 
the  tools,  their  efficiency,  and  correctness  and  the 
maintenance  of  configuration  management. 

2.  Test  Programs  -  The  software  used  in  the  generation  of 
test  data,  the  running  of  test  cases,  and  in  test  data 
reduction.  Requirements  stem  from  system  and  hardware 
test  specifications.  Customer  interface  is  via  the 
approval  of  test  specifications.  Examples  are: 
testwere;  raid  tape  generators;  card  test  programs; 
hardware  acceptance  test  programs;  and  manufacturing 
test  programs.  The  software  used  in  automated  test 
equipnent  fall  in  this  category. 

3.  tointenance  Programs  -  The  software  used  in  fault 
detection  and  fault  isolation.  Differ  from  test  pro¬ 
grams  in  that  they  are  more  go-no  go  type  programs  than 
test  of  specific  parameters.  Requirements  stem  from 
system  specifications  for  MTTR  and  system  availability. 
Although  the  functions  are  more  often  found  embedded  in 
the  application  software,  these  programs  have  tradi¬ 
tionally  been  off-line.  Customer  interface  is  in  the 
specification  of  MTTR  and  availability  goals.  Examples 
are:  performance  monitoring/fault  location  programs; 
hardware  diagnostics;  and  calibration  programs. 

4.  Computer  Aided  Manufacturing  Programs  -  This  software 
is  used  to  generate  the  programs  used  in  (embedded  in) 
production  tools  producing  terdware.  They  are  the  logi¬ 
cal  equivalent  to  the  programming  support  environment. 
Requirements  stem  from  the  need  for  lowered  cost  and 
improved  accuracy  and  quality  in  the  manufacturing  pro¬ 
cess.  Customer  interest  is  in  repeatability  of  the 
production  process  controlled  by  the  programs  generated 
in  this  environment.  Examples  are  the  AEAM  II  programs 
and  the  HERCULES  software. 
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ENGINEERING  SOFTWARE 


1.  Computer  Aided  Design  Software  -  This  software  is  used 
to  improve  the  productivity  of  the  hardware  engineer  in 
the  design  process.  It  tends  to  be  graphic  oriented 
and  makes  heavy  use  of  simulation  to  verify  designs. 
Requirements  stem  from  need  to  improve  productivity  and 
quality  of  the  engineering  process.  Most  often  is  in 
form  of  software  running  on  main  frames  but  is  now 
being  adapted  to  design  work  stations  running  on  mini 
computers.  Examples  are  the  TEGAS  software,  SPICE,  and 

,  Simscript  programs.  The  customer  interest  seems  to  be 
a  desire  to  standardize  and  make  available  to  all  of 
industry  the  productivity  gains  from  use  of  such 
software. 

2.  Computer  Aided  Engineering  Software  -  The  software  used 
to  increase  the  productivity  of  systems  and  software 
engineering  process.  The  software  in  this  category  is 
just  beginning  to  appear  and  project  use  of  such  sys¬ 
tems  is  limited.  The  category  is  one  of  the  next  areas 
of  emphasis  for  productivity  improvement.  Requirements 
stem  from  need  to  improve  the  individual  productivity 
of  engineers  doing  requirements  analysis,  specifica¬ 
tions,  top  level  design  and  systems  architecture. 
Software  generally  runs  on  mini  computers  and  there  is 
a  drive  towards  use  of  work  stations.  The  customer 
tends  to  lump  this  software  with  the  programing 
environment. 


ADMINISTRATIVE  SOFTWARE 


Administrative  software  supports  the  administrative  or 
management  areas  of  the  company.  This  software  is  not 
directly  connected  with  the  development  of  a  product  but  is 
used  by  the  functional  areas  as  described  below. 


1.  Financial  Software  -  The  software  used  to  manage  the 
company's  financial  books,  distribute  cash  and  funds, 
plan  the  company's  and  organizations'  financial  posi¬ 
tion,  collect  and  price  cost  input  data.  This  software 
is  normally  under  the  direct  or  indirect  control  of  the 
company's  financial  organizations  who  are  responsible 
for  the  integrity  of  the  financial  data. 

2.  Project  Management  Software  -  The  software  used  to 
manage  and  administer  projects,  (both  contracts,  bids, 
and  IR&D) .  These  applications  are  used  to  report  the 
project  cost  -  plans  and  actuals  -  schedules,  and 
management  work  breakdown.  These  reports  are  used  by 
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project  offices,  the  assist  organizations  and  the  cus¬ 
tomers  for  management  purposes  rather  than  engineering 
or  manufacturing  processes. 

3.  Employee  Services  Software  -  The  software  used  to 
manage  the  company's  employee  status,  compensation  and 
benefit  data.  This  software  is  used  and  managed  by  the 
company  Hunan  Resource,  Payroll  and  Employee  benefit 
organizations.  REports  generated  by  these  systems  are 
mainly  used  by  the  above  organizations  for  their  own 
personnel  management  and  to  the  government  for  required 
Human  Resource  reporting. 

4.  Engineering  Configuration  Data  Software  -  The  software 
used  to  manage  the  configuration  of  the  parts  in  a  pro¬ 
duct  during  the  engineering  development  of  that  product 
but  not  the  final  repository  of  the  configuration  of 
the  product.  This  software  may  also  include  parts  pro¬ 
curement,  provisioning  and  inventory  software.  These 
applications  are  managed  by  an  engineering  support 
organization  such  as  a  Data  Ptenagement  department  but 
reports  are  used  by  many  engineering  and  manufacturing 
organizations. 

5.  Manufacturing  DBta  Software  -  The  software  used  to 
manage  the  manufacturing  tasks  and  their  associated  use 
of  parts.  This  manufacturing  or  production  control 
software  is  managed  by  the  manufacturing  organizations 
who  are  responsible  for  the  integrity  of  the  data. 

6.  Conmunications  Systems  -  The  software  used  only  in 
voice  and  data  conmunications  for  the  company's  inter-., 
nal  conmunications  network  and  not  involved  in  any  pro¬ 
ducts. 


PERSONAL  SOFTVftRE 

Since,  by  definition,  it  is  desired  to  maintain  a  category 
of  software  that  is  not  constrained  in  any  way,  it  is  inap¬ 
propriate  to  include  subcategories  in  this  use-field. 
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THIRTEEN  DOCUMENTATION  PROBLEMS 
THAT  DON'T  SEEM  TO  GO  AWAY 
by 

W.  W.  Thomas 
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INTRODUCTION  -  Twenty-five  years  of  documentation  management 
reflected  by  the  history  of  this  division  allow  us  to  look  at 
some  of  the  issues  with  an  eye  toward  sorting  out  the  crises  and 
deciding  which  are  fires  and  which  may  be  just  smoke.  The  points 
I  hope  to  make  summarize  some  of  these  problems.  They  are 
personal  views  offered  within  the  true  intent  of  our  charter  to 
stimulate  discussion  that  will  influence  our  government  toward 
maximum  defense  for  our  tax  dollar. 

DRAWINGCOSTING  -  How  do  we  know  the  cost  of  drawings  is  too 
high?  Since  the  formation  of  this  division,  DOD  leaders  have 
expressed  the  opinion  that  if  we  could  get  a  fix  on  the  cost  of 
data,  we  would  have  a  start  on  where  to  reduce  these  costs. 

Every  new  generation  of  the  government  people  in  charge  starts 
the  effort  again. 

This  may  be  fine  for  some  forms  of  documentation  where,  if  the 
customer  doesn't  buy  the  data,  no  effort  gets  spent.  But 
drawings  are  different.  For  many  disciplines,  drawings  start  at 
the  origin  of  the  engineering  process,  and  their  development  is  a 
part  of  that  process.  Multiple  iterations  generate  drawings  that 
never  get  released.  The  revisions  inherent  in  the  engineering 
process  add  redraw  costs  that  are  certainly  not  separable  from 
the  cost  of  the  engineering  itself. 

Some  choose  the  route  of  costing  drawings  as  the  cost  of  printing 
of  a  set.  This  is  mostly  a  pul  1 -and-reproduce  cost,  and  in  no 
way  reflects  the  cost  of  drafting  practices.  There  is  nothing 
there  that  needs  to  be  measured,  and  thereby  reduce  drawing 
costs. 

It  is  unfortunate  that  even  now  a  new  group  of  specialists  has 
under  discussion  a  new  way  of  costing  the  1423  form.  I  would 
like  to  suggest  we  forget  any  summation  of  these  costs  and  get  on 
with  the  process  of  eliminating  those  features  of  our 
specifications  and  standards  that  contribute  unnecessary 
constraints  wherever  they  are  and  regardless  of  how  little  they 
save.  This  is  an  excellent  example  of  where,  if  we  watch  the 
pennies,  the  dollars  will  take  care  of  themselves. 

ON  TO  COMPUTERS  -  The  challenge  of  computer  aided  interactive 
graphics  first  hit  this  division  in  1964.  By  1965,  our 
discussion  had  spawned  a  series  of  national  magazine  articles  on 
the  computer  replacing  the  drawing  board.  Thurber  Moffat 
published  a  prediction  of  interactive  graphics  that  rereads  so 
accurately  it  could  have  been  written  by  CALMA  or  Applicon  for 
today's  brochures. 

Thurber  was  absolutely  right.  His  prediction  of  five  years  till 
all  engineers  would  have  a  terminal  is  possibly  still  five  years 
away,  but  it  is  coming,  and  with  it  the  five-alarm  fire  of 
documentation  problems  ranging  from  configuration  control  of  the 
data  base  to  delivery  of  data  that  never  becomes  hard  copy. 
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CEO  OR  BUST  -  Are  data  managers  and  configuration  management 
special ists  a  disadvantaged  sect  because  of  the  level  to  which 
they  report?  Probably  not,  but  the  person  involved  in  the 
diplomatic  squeeze  inherent  in  these  jobs  often  believes  his 
problems  are  unique. 

For  example,  how  about  the  unfinished  drawing  your  group  is 
working  on  which  is  pulled  out  for  a  print  "right  now"  because 
"we  need  it  now;  clean  it  up  later"?  How  about  being  told  to 
make  the  change  effective  "all"  with  the  first  product  on  the 
shipping  dock? 

How  about  being  made  organizationally  responsible  to  one  of  many 
middle  engineering  managers  and  told  to  just  serve  the  whole 
engineering  department  as  you  can  find  the  time  and  manpower? 

How  about  finding  out  about  the  tech  manual  requirements  when  the 
assembly  line  needs  to  insert  the  manual  in  the  shipping 
container? 

At  the  risk  of  disillusioning  some,  we  need  to  remind  ourselves 
that  these  are  the  awful  frustrations  of  almost  any  service  job. 
They  are  also  challenges  to  good  middle  managers.  We  all  hear 
complaints  about  documentation  management  reporting  levels  being 
too  low.  Surprisingly,  reliability  managers  feel  the  same  way. 

So  do  managers  of  test  groups,  factory  production  departments, 
and  accountants. 

If  you  are  a  good  manager,  it  probably  doesn't  mean  much  that  you 
don't  report  directly  to  the  president.  If  you  have  missed  my 
point,  the  problem  I  would  like  to  articulate  here  is  that  I 
think  we  are  wasting  too  much  of  our  professional  effort 
discussing  the  profession  of  data  management.  Let's  stop 
studying  the  organizational  status  of  the  data  manager  and  get  to 
work  efficiently  managing  data. 

UNIFORM  TECHNOLOGY  TRANSFUSION  -  Transmission  of  technology  by 
data  without  personal  interface ,  especially  for  competitive 
reprocurement,  is  one  of  our  more  subtle  problems. 

Of  all  the  problems  faced  by  the  documentation  specialist, 
possibly  the  most  intellectually  frustrating  one  involves  the 
embedded  belief  on  the  part  of  the  world  that  everything  there  is 
to  be  known  about  a  product  can  be  communicated  in  a  competitive 
reprocurement  data  package.  This  just  isn't  so,  as  proven  by  the 
many  cases  where  competitive  acquisitions  have  proceeded  for 
years,  and  suddenly  a  new  low  bidder's  product  starts  to  perform 
erra  t i ca 1 1 y . 

The  drawings  and  specifications  in  the  reprocurement  data  package 
are  only  the  beginning.  Knowledge  of  the  business,  the  processes 
and  the  technology  are  equally  important  and,  in  many  cases, 
probably  not  reducible  to  documentation. 
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Part  of  the  problem  here  is  that  none  of  us  fully  understands 
just  how  much  we  take  for  granted  as  part  of  the  processing. 
Another  part  of  the. problem  is  that  our  competitors  also  know  as 
much  as  we  do  about  many  of  these  same  things.  Thus,  a  data 
package  is  often  presumed  to  be  suitable  for  competitive 
reprocurement  only  because  all  competitors  who  build  to  it  know 
about  the  things  the  designer  inadvertently  left  out.  The  crisis 
comes  when  the  inexperienced  supplier  bids  the  job,  wins  it,  and 
finds  out  he  doesn't  know  enough  about  the  business  to  be  able  to 
follow  the  totally  complete  and  spec-compliant  data  package  he 
has  been  given. 

Where  is  the  problem?  I  think  it  rests  with  those  who  fail  to 
understand  that  the  technical  data  package  is  a  fragile  and 
incomplete  communication  device  at  best.  They  are  the  ones  who 
insist  that  it  be  perfect  regardless  of  cost,  and  they  are 
incorrect  in  doing  so  —  at  significant  cost  to  our  military 
defense  budget. 

MANUFACTURING  PROCESSES  -  Probably  one  of  the  reasons  why  the 
issue  of  whether  the  drawing  package  ever  communicates  all  about 
a  design  to  a  second  competitive  source  has  to  do  with  a  basic 
axiom  of  drawing  practices.  This  is,  "never  do  your  processing 
in  the  drawing  package  unless  there  is  no  other  way  to  describe 
what  you  want  but  to  describe  how  to  get  it."  The  old  rule, 

"Show  what — not  how,"  applies  here  every  bit  as  much  as  it  does 
to  mil  specs,  standards  and  contracts.  It  should  be  obvious  that 
how  you  make  a  part  or  assembly  or  a  weapons  system  will  vary 
with  technologies  available,  factory  tooling,  production  rates, 
machine  loading,  and  labor  skills  available.  Even  a  robot  may 
come  on  the  scene.  Locking  the  process  into  the  competitive 
reprocurement  package  tends  to  negate  that  essential 
manufacturing  flexibility. 

ESCAPED  PROPRIETARY  INFORMATION  -  Many  of  you  may  never  have 
heard  of  Denham  Scott  and  his  "swiss  cheese  drawings,"  but  Denham 
was  a  real  person  who  for  years  delivered  to  the  services 
drawings  with  big  holes  in  them  where  proprietary  information  had 
been  cut  out.  You  probably  understand  that  his  may  have  been  the 
only  company  that  truly  protected  its  proprietary  information. 

In  my  opinion,  the  government  policy  on  proprietary  protection 
has  elements  of  being  unfair  to  the  point  that  the  defense 
industrial  base  is  reduced  by  this  unfairness.  Companies  usually 
prefer  to  get  the  job,  rather  than  lose  it  through  refusal  to 
give  up  proprietary  information.  So,  the  companies  stand  their 
ground  only  in  major  cases  and,  even  then,  reluctantly  disclose 
only  when  the  issue  is,  "Give  in  and  win,  or  refuse  and  lose." 

The  frightening  aspect  of  this  situation  is  that  probably  some 
companies  are  just  staying  out  of  the  game. 


Is  this  problem  smoke  or  fire?  It  is  probably  smoke  for  fast 
paced  technologies  or  very  complex  businesses.  It  is  probably 
fire  for  highly  competitive  companies  in  stable  technology  areas. 


We  have  worked  this  problem  for  a  long  time  with  the  military  and 
had  almost  no  change  in  its  posture.  The  thing  we  who  live  by 
our  defense  business  can  never  know  is  how  much  of  the  industrial 
base  is  just  not  participating  in  defense  work  because  of  these 
policies.  How  to  find  this  out,  and  to  correct  the  causes  are 
two  projects  that  have  been  within  the  charter  of  both  the  ADPA 
and  this  division  for  years  without  satisfactory  resolution. 

I  think  we  need  one  guiding  rule  here  at  the  present  time,  until 
we  get  the  situation  changed:  If  you  have  a  true  secret  and  need 
to  protect  it  for  your  business,  don't  disclose  it  to  the 
government. 

NON-MILITARY,  WHERE  PRACTICAL  -  The  issue  of  mil  spec  or 
commercial  is  the  scene  of  some  of  ADPA's  greatest  successes. 
Surely,  ADPA,  with  help  from  Bob  Franciose,  Maurie  Taylor  and 
Chet  Nazian,  broke  extremely  successful  ground  when  ANSI 
Standards  became  defense  standards  and  reduced  to  a  whisper  the 
roar  of  protest  over  the  40%  delta  dollar  differential  quoted  so 
widely  when  70327  was  first  issued. 

I  hope  in  opening  this  beautifully  successful  case  we  didn't  open 
Pandora's  box.  There  is  a  place  for  military  versions  of 
commercial  products,  but  to  mislead  the  government  into  buying 
commercial  when  it  falls  apart  the  first  time  a  depth  bomb  goes 
off  under  the  keel  is  no  contribution  to  the  defense  effort.  Do 
we  have  a  problem  here?  I  feel  there  is  probably  more  smoke  than 
fire,  but  the  situation  bears  close  watching. 

PAR  DATA  REQUIREMENTS  ON  THE  CDRL  -  The  exemption  from  listing  of 
DaR  required  items  on  the  CDRL  is  one  of  the  least  understood  of 
DOD's  positions.  It  represents  a  'heads  we  win,  tails  you  lose’ 
attitude  on  the  part  of  the  government.  The  CDRL  was  possibly 
the  best  idea  ADPA  ever  convinced  the  government  to  adopt.  The 
slight  exception  for  DAR  data  requirements  makes  the  CDRL 
"complete,  all  but,"  and  this  becomes  one  of  life's  little 
documentation  management  crosses  to  bear. 

Fortunately,  along  with  CDRLs  came  a  maturity  in  data  managers 
that  partially  compensates  for  this  unfairness,  so  this  problem 
is  probably  more  smoke  than  fire.  It  is  a  situation  that,  in 
fairness,  should  be  corrected  just  the  same. 

ALL  THOSE  MONO-DETAILED  SYSTEMS  -  Unique  military  practices,  such 
as  the  mono-detailed  drawing  Tystem  and,  for  that  matter, 
assignment  of  military  part  numbers  to  contractors'  drawings,  are 
still  a  problem.  This  problem  has  been  around  for  over 
twenty-five  years.  I  would  like  to  think  that  either  industry 
could  be  made  to  understand  why  these  practices  are  necessary  or 
that  the  practices  be  eliminated.  They  do  cost  the  taxpayer  a 
good  bit  of  money. 


Are  there  enough  of  these  cases  to  call  it  a  fire?  No.  I  would 
rate  this  as  a  smokey  fire,  but  one  well  worth  calling  one  alarm. 


THEN  INSPECT  IT  -  As  many  of  you  know,  I  have  for  years  been 
opposed  to  the  idea  that  statistical  quality  control  or  after- 
the-fact  inspection  of  drawings  when  applied  to  the  drawing 
package  under  a  MIL-Q-9858  type  approach  is  the  wrong  way  to  get 
quality  in  documentation.  Every  so  often,  product  assurance 
types  explain  how  they  will  inspect  quality  into  the  drawings, 
and  we  see  unnecessary  costs  emerge  again.  As  in  a  great  number 
of  related  issues,  sometimes  we  lose  sight  of  the  fact  that  a 
good  set  of  drawings  has  its  quality  built  in,  not  laid  on  during 
a  post-completion  review,  and  certainly  not  achieved  by  a  count 
of  defects. 

INTRODUCING  SPECIFICATION  AND  SOURCE  CONTROL  DRAWINGS  -  We  have 
an  awful  dilemma  where  we  have  allowed  a  specification  control 
drawing  to  be  defined  as  a  document  which  is  seldom  a 
specification,  seldom  controlling,  and  sometimes  not  even  a 
drawing.  I  know  Ted  Golmis  and  your  subcommittees  are  working  on 
the  redefinition  of  the  specification  and  source  control  drawing. 
I  happen  to  feel  the  terms,  however  incorrect  they  are,  are  so 
embedded  in  the  culture  that  we  would  cause  more  trouble 
correcting  them  than  living  with  what  we  have.  But  this 
educational  problem  will  continue  to  plague  us  for  quite  a  while. 
I  question  whether  minor  cosmetic  treatment  can  solve  it,  and  I 
doubt  if  major  surgery  is  justified.  This  appears  to  be  a 
dilemma  we'll  just  have  to  live  with. 

0  STANDS  FOR  ZERO  SIGNIFICANCE  IN  DRAWING  NUMBERS  -  Another 
smokey  area  where  I  suspect  there  to  be  fire  involves  recurring 
pressure  for  significant  numbering  systems.  Flat  out,  I  would 
like  to  recommend  a  policy  of  non-significant  drawing  and  part 
numbering  systems,  and  have  the  ANSI  or  mil  specs  implement  this 
policy.  There  are  some  who  see  merit  somewhere  in  the  idea  of 
special  significance  to  part  number i.ng  and  drawing  numbering 
prefix  letters  and  symbology  ad  nauseum.  There  seems  to  be  a  lot 
of  smoke  here,  even  though  the  military  specs  are  currently  quite 
good.  It  is  the  special  imp! ementation  that  causes  much  of  this 
problem. 

Of  course,  when  pressing  for  significance,  one  has  to  oppose  the 
15  character  limit  in  part  numbers,  which  just  adds  to  the 
reasons  for  opposing  significance.  Charlie  Fisher  has  asked, 

"Has  anyone  ever  suggested  using  National  Stock  Numbers  (NSNs) 
and  letting  individual  contractors  go  their  own  way  as  to  part 
numbers?"  This  would  require  some  far  better  transmission  of 
National  Catalog  listings  to  the  industry,  but  could  be  a 
solution  to  the  duplicate  part  number  problems  that  abound. 

These  duplicate  part  number  problems  could  grow  exponentially  if 
significant  numbering  systems  were  to  be  encouraged,  and  the  15 
digit  lid  were  to  be  removed. 

The  real  fire,  however,  is  breaking  out  in  the  identification  and 
co nf i gu r a t i on  management  practices  for  deliverable  software, 
where  a  new  generation  of  specialists  with  no  documentation 
background  think  they  have  invented  a  new  wheel.  In  this  area, 
the  problem  is  definitely  two  alarm,  headed  possible  for  three. 
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NEW  ENGINEERS  NEED  TEACHING  -  More  and  more  engineers  are 
graduating  semi -1  iterate  in  one  of  their  basic  languages.  This 
is  a  real  fire,  and  it's  in  our  own  backyard,  not  the 
government's.  When  one  writes  poorly,  with  improper  grammar, 
spelling  and  sentence  structure,  one  is  called  semi -literate 
because  one  has  failed  to  master  the  language.  Why  shouldn't  we 
consider  the  engineer  who  can  neither  draw  nor  read  drawings 
equally  illiterate?  Yet  a  great  many  colleges  are  dropping  all 
drafting  courses  from  their  curriculum. 

DOCUMENTATION  -  There  they  are.  Thirteen  problems  that  don't 
seem  to  go  away.  Thirteen  issues  that  nag  away  at  effective 
documentation  practices  while  adding  costs  to  our  defense 
product.  Is  it  possible  that  this  division  in  its  next 
twenty-five  years  can  resolve  or  reduce  to  insignificance  a 
number  of  these?  To  do  so  would  be  a  magnificent  way  to  offer 
our  contribution  to  a  more  effective  industry /defense  team. 
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WORKSHOP  PANEL  SUMMARY  REPORTS 


ADPA 

25th  ANNUAL  MEETING 
TECHNICAL  DOCUMENTATION  DIVISION 


Workshop  #1  -  Data  Management 


Attendance-  Industry  42(62%) 

Government  26(38%) 

(See  Attachment) 

Approach  -  The  format  of  this  haif-day  workshop  included  three  separate 
parts;  a  question-answer  session  where  the  customary  questions/comments 
on  the  available  question  cards  were  discussed;  a  discussion  period  dealing 
with  the  two  prior-identified  topics;  and  a  period  devoted  to  responding  to 
any  topics  generated  at  the  workshop. 

Question  -  Answer  Period 

Messrs.  Jim  Richardson,  OUSD-RE(DMSSO)  and  Vince  Mayolo,  EG&G, 
constituted  a  panel  which  fielded  the  question  cards  which  were  turned  in. 
These  topics  are  summarized  below,  as  interpreted  by  the  workshop  chair. 

Q-1  "We've  heard  rumors  of  the  demise  of  the  MIAG.  What  is  happening  to 
the  MIAG  and  will  there  be  on-going  action  to  eliminate  DID 
redundances?" 

A-1  The  MIAG  has  been  abolished.  It  is  being  replaced  by  the  Technical  Data 
Management  Advisory  Group,  with  representatives  from  all  the  Services. 
Among  the  tasks  to  be  handled  will  be  a  review  of  the  current  DID's, 
expected  to  take  some  18  months. 

0-2  "Is  there  a  MIL-SPEC  which  covers  COM  (Computer  Originated 

Microfilm)?  If  not,  are  there  any  plans  to  prepare  a  new  one  or  revise 
MIL-M-9868?" 

A-2  There  is  no  action  on  a  MIL-SPEC  now.  With  all  of  the  film  involved  in  38 
DOD  repositories,  there  is  some  review  going  on  (e  g.,  the  Army's 
DESRED  effort).  There  are  discussions  on  tape/film  scanability 
considerations  and  the  make  up  of  a  data  base.  Initial  systems  dealing 
with  this  may  be  in  operation  in  about  15  monthsat  Huntsville, 
Philadelphia  and  Sacramento  ALC. 
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Q-3  "How  do  you  handle  engineering  (or  other  organization)  approvals  on 
drawings  in  a  "paperless"  system?" 

A-3  From  a  national  point  of  view,  this  is  one  of  a  number  of  problems 
identified  for  which  a  decision  has  not  been  made.  A  number  of 
individual  programs  have  reported  satisfaction  with  handling  this  by 
means  of  systems  varying  from  the  use  of  organization  approval  codes  to 
the  use  of  no  approvals  (signa^.e)  at  all. 

Q-4  "We've  heard  that  Public  Law  96-511  affects  Data  Management.  What  is 
happening  as  a  result  of  this  law  and  what  might  we  expect  in  the 
future?" 

A-4  P.L.  96-51 1,  Paperwork  Reduction  Act  of  1980  removes  those  data 

previously  exempt  from  OMB  control  (Technical  Documentation)  under 
the  Federal  Reports  Act  of  1 942.  This  act  provides  that  all  data 
requirements  must  have  prior  OMB  approval.  Information  collection 
requests  must  use  the  DID  and  DD  1423.  The  law  impacts  all  Federal 
Agencies  (not  just  DOD)  and  the  following : 

DODI  5010.12 
DODD5000.19  Enel  #5 
DOD  5000. 19L  Vol.  II  (AMSOL) 

DODD  41 20.3 
DOD412Q.3M 
MIL- STD-961 
MIL- STD-962 
MIL-STD-963 

New  MIL- STD  on  hardware  specs 
FAR/DAR  clauses 
Collection  of  info  in  RFP's 

A  new  implementation  document  will  be  necessary. 

Approved  (standard)  documentation  requirements  can  only  be  used  as  is 
or  portions  deleted;  any  additions  require  additonal  OMB  approval. 

Q-5  ( 1 )  QA  Data  Item  Inspection  Requirements 

•  What  are  the  guidelines? 

•  Who  does  it  and  when? 

(2)  Data  item  Packing  &  Packaging  Requirements 

•  What  are  the  guidelines? 

•  Aperture  cards/original  dwgs/tech  manuals 

•  Who  does  it  and  when?" 

A-5  About  one  quarter  of  the  attendees  indicated  that  they  are  subject  to 
DCAS  audit  of  Data  Management  Quality  Assurance.  It  was  reported 
that  there  is  a  heavier  emphasis  on  data  quality  in  the  new  rewrite  of 
MIL-Q-9858.  Further,  there  is  now  in  limited  coordination  a  NavAirQ.A. 
program  for  Tech  Manuals.  One  company  reported  more  than  one  Q  A 
(drawings,  T.O.'s,  etc.)  and  many  differing  emphasis,  depth  of 
requirements  and  organization. 
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Prior  Identified  Topics 


Two  current  topics  were  identified  for  workshop  discussion ;  outline 
considerations  were  available  to  workshop  participants  at  meeting 
registration  as  shown  below. 

TOPIC  A 


Changes  in  Data  Management  to  Cope  with  the  Paperless  Office 

•  With  CAD/CAM,  Drawings  on  Tape  vs  Paper 

•  Impact  on  Data  Packages  &  Repositories? 

•  Standard  language/format  for  drawing/parts  lists? 

•  As  Government  begins  to  Standardize 

•  What  penalties  for  wrong  guess  (e.g.  DI-E-1104A)? 

•  How  much  interactive  access  is  acceptable? 

•  Where  is  line  drawn  on  third-party  involvement? 

•  Utilization  of  technology  without  invasion  of  Contractor's  rights 

•  Does  standardization  of  formats,  graphics,  languages,  hardware, 
software  out-prioritize  contractor  ingenuity,  initiative, 
independence? 

Much  activity  in  data  automation  was  reported  by  the  participants.  Reported 
results  varied  from  "total  disaster"  to  "quite  satisfactory".  A  number  of 
problems  were  identified: 

lack  of  standardization-language,  graphics 
documents  lost  in  word  processor 
difficulty  in  control-access  problems 
repagination  constraints 
handling  classified  information 
indexing 

need  for  paper  products-dual  systems 
training  requirements-old  guard  syndrome 

Participants  indicated  varying  degrees  of  progress-some  have  had  gradual 
growth  from  dual  products  (paper  and  screen)  to  the  point  where  all 
drawings  now  are  digitized  (after  7  years  of  development).  DOD 
representatives  reported  efforts  underway  to  automate  repositories. 
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Discussions  brought  out  a  number  of  cautions: 

It  is  too  soon  to  standardize  some  things; 

Internal  computerization  is  big  need; 

Access  controls  =  not  minor,  but  workable; 

Length  of  time  tapes  in  storage  &  remain  valid,  unknown; 

Need  feasibility  studies 

cheaper  engineering  task  may  result  in  more  expensive  mfg  task 
new  computer  capacity  fills  up  immediately 
pay-off  depends  on  effective  integration 
success  requires: 

customer  confidence 
innovative  thinkers 
supportive  management 
bottom  line  =  trust,  both  ways 
customer/contractor 
employer/employee 


TOPIC  B 


The  Data  Manager's  role  in  contract  negotiations 

•  Depth  of  Involvement 

•  Actual 

•  Desirable 

•  Focus  of  Involvement 

•  Passive-as  requested 

•  Active-as  perceived  necessary 

•  Pre-RFP 

•  SOW 

•  MILSpec/Stds 

•  CDRL 

•  Schedule/General  &  Special  Provisions 
(incl  DAR,  Rights  in  Data,  Software,  etc.) 

•  Cost-benefit  Analysis 

•  RFP  -  Delta 

•  Post-RFP 
Attendees: 

Jerry  Cichowicz  -  Chemical  Systems,  Aberdeen 
Larry  Dietz  -  Arradcom,  Dover  N.J. 

Dan  Gillian  -  Rockwell  Int'l,  Richardson  TX 
Carl  Lewis  -  General  Electric,  Wilmington,  MS 
Ron  VanBuskirk  -  Aerojet  Electro  Systems,  CA 
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It  was  a  consensus  that  there  is  a  definite  benefit  in  involving  the  data 
manager  in  pre-RFP,  contract  negotiations  and  post-RFP  activities. 

It  was  concluded,  however: 

A.  Depth  of  involvement  depends  on  organizational  structure  and 
therefore  leads  to  three  (3)  levels  of  involvements: 

(1)  Data  management  function  in  place  with  involvement  throughout  a 
program 

(2)  During  initial  phase,  on  a  consulting  basis,  but  not  thereafter 

(3)  None  -  Decisions  made  by  program  office,  contracts  or  other 
organizations 

B.  The  contract  data  items  list  is  established  in  one  (1)  of  three  (3)  ways  and 
is  again  organizational  sensitive: 

(1)  By  comparison,  analogy  -  past  programs 

(2)  "Pick  List"  by  functional  organization 

(3)  Justified  item  by  item 

Workshop-Generated  Topics 

A.  A  question  was  raised  relative  to  the  length  of  data  warranties  and  the 
applicability  of  the  latent  defects  cause.  Response  indicated  data 
warranties  usually  of  three  years  and  little  application  of  the  latent 
defects  clause  to  data. 

B.  It  was  pointed  out  that  with  the  coming  broad  application  of  the  FAR, 
the  DD  Form  1423  has  been  nominated  for  use  as  a  Fed  Std.  (Anticipation 
that  FAR  will  be  issued  about  April  '84).  Accordingly,  it  would  appear 
timely  to  look  at  and  recommend  any  improvements  to  the  DD  1423  The 
workshop  chair  agreed  to  receive  any  current  recommendations, 
combine  with  last  year's  recommendations  and  submit  to  DM  SSO.  (As  a 
side  comment,  it  would  appear  that  the  use  of  current  AFSC  forms  707, 
708, 709  would  have  to  be  discontinued). 

C.  Reference  was  made  to  our  earlier  CDM  Section  meeting  addressing  the 
matter  of  DM  certification.  It  was  recognized  that  nothing  further  could 
be  done  without  an  agreed-to  definition  of  the  DM  function.  Wally 
Rook,  Al  Signor  and  Ea  Avery  agreed  to  convene  subcommittee  meetings 
this  coming  year  to  come  up  with  a  consensus  definition.  Others 
expressing  an  interest  in  working  on  this  subcommittee  include.  Jim 
McGregor,  Bob  Lint,  Fred  Tessier,  Ron  Van  Buskirk,  C.  Eschenback,  Ron 
Schrage,  Herb  Atkins,  Bill  Thomas,  Vic  Fredette,  Jr.,  and  Dr.  Ray  Calhoun 


John  R.  Hart 

Workshop  #1  Data  Management 
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Stacey,  Thomas  Massey  Ferguson  Perkins  Inc  32SOO  Van  Born  Rd 

(J1i)S95  96/4  Box  81 1 

Wayne.  Ml  48184 


WORKSHOP  NO.  2 


ENGINEERING  DRAWINGS 


Acting  Mrs.  LORNA  BURNS 

Chairman:  Corporate  Head,  Engineering  Design  Standards 

Hughes  Aircraft  Company 
El  Segundo,  California 


Panel  Mr.  RICHARD  R.  BARTA 

Members:  Manager,  Engrg  Standards  and  Product  Safety 

IBM  Corporation 
Owego,  New  York 

Mr.  MAURICE  E.  TAYLOR 

Chief,  Specifications  and  Standards  Branch* 
Army  Armament  R&D  Command 
Dover,  New  Jersey 


Recorder:  Mr.  WALTER  E.  THIELE 

General  Motors  Corporation 
Delco  Systems  Operations 
Goleta,  California 


♦Preparing  Activity  for  DOD-D-1 000  and  DOD-S TD-100. 
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STATUS  OF  Y14  DRAFTING  PRACTICES 
(new/recently  revised) 


YI4.5  Dimensioning  and  Tolerancing  (MR.  Nicovich)  -  Revised  1982. 

Y14.6  Screw  Thread  Representation  (Mr.  Meitz)  -  Supplement 
issued  covering  metric  screw  threads,  1981. 

Y14.8  Casting  (Mr.  Pickard)  -  Revision  in  work. 

Y14.9  Forgings  -  This  subommittee  is  looking  for  experts  to 
participate  in  updating  this  standard.* 

Y14.13  Springs  (Mr.  Guetzlaff)  -  Revised  1981. 

Y14.15  Electrical  and  Electronic  Diagrams  (Mr.  Muller)  -  IEEE 
has  assumed  responsibility  for  this  standard;  a  new 
number  will  be  assigned  at  the  next  revision.  Only 
Logic  Diagram  Preparation  is  currently  in  work. 

Y14.18  Drawings  for  Optical  Parts  (Mr.  Beavers)  -  New  standard 
issued  1982. 

Y14.24  Types  and  Application  of  Engineering  Drawings  (Mrs.  Burns)  - 
New  standard  in  work. 

Y14.26  Computer  Aided  Preparation  of  Product  Definition  Data 
(Mr.  Jones)  -  New  standard  issued  1981. 

Y14.34  Parts  Lists,  Data  Lists  and  Index  Lists  (Mr.  Dubocq)  - 
New  standard  issued  1982. 

Y14.35  Drawing  Revisions  (Mr.  Derry)  -  New  standard  in  work. 


*  Recommendations  should  be  submitted  to  R.F.  Franciose, 
(408)  925-6880. 
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WORKSHOP  NO.  2 
ENGINEERING  DRAWINGS 


The  Engineering  Drawing  workshop  was  attended  by  approximately  64 
people  (see  List  of  Attendees);  approximately  one  third  Government 
and  two  thirds  Industry. 

As  the  result  of  the  general  discussions  and  more  than  30  questions, 
nine  new  action  items  for  the  Engineering  Drawing  Section  were 
identified. 

I.  GENERAL  DISCUSSIONS 

A.  Drawing  Requirements  for  Paperless  Data 

ACTION  ITEM:  An  ad  hoc  committee  was  established  to 
evaluate  the  standards  needed  for  paperless  data. 

This  ad  hoc  group  faces  a  revolutionary  challenge  and  much  careful 
work.  But  inspite  of  this,  six  individuals  responded  to  this 
challenge. 

Since  the  advent  of  CAD  generated  data,  the  requirements  of  various 
drawing  standards  have  been  challenged  as  archaic.  Some  of  these 
standards  have  been  revised  to  facilitate  CAD  documentation  prepara¬ 
tion.  (For  example:  ANSI  Y14. 2-1980  permits  the  use  of  a  single 
line  width  on  CAD  prepared  drawings.  About  half  of  those  present  use 
single  line  width  plots.)  But  these  kinds  of  changes  only  address 
elementary  applications  of  automation. 

What  is  the  Problem?  As  an  alternative  to  hard  copy  or 
microfilm  of  drawings,  new  methods  for  developing,  com¬ 
municating,  storing,  retrieving,  and  using  product  defi¬ 
nition  data  are  rapidly  gaining  acceptance.  (Gen.  Morelli, 

Mr.  Lazorchak,  Col.  Larimer,  Col.  Kuster,  Col.  Tracy,  and 
almost  every  other  speaker  this  year  described  this  need.) 

The  potential  payoff  for  these  new  methods  is  dramatic 
increase  in  productivity.  A  wedge  is  being  driven  between 
the  traditional  engineering  drawing  community  and  this 
new,  but  real  product  definition  data — the  stakes  are  too 
high  to  let  tradition  get  in  the  way.  Precious  dollars  are 
being  spent  in  meeting  obsolete  drawing  requirements. 


B.  Changes  to  DOD-STD-IOQ 

Mr.  Taylor  summarized  the  changes  to  DOD-STD-IOOC  that  are  contained 
in  Notices  3  and  4.  These  notices  are  dated  March  and  May  1983 
respectively.  Notice  3  incorporates  numerous  editorial  changes 
which  had  been  requested  by  the  ADPA/TDD  Engineering  Drawing  Section 
and  invokes  several  new/revised  standards.  Notice  4  corrects 
ommissions  that  were  introduced  by  Notice  3.  No  problems  were 
presented  by  attendees. 
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C.  Implementation  of  ANSI  Y14.5M-1982 


Notice  that  this  revision  of  Y14.5  has  been  invoked  by  DOD- 
STD-100C,  Notice  3  was  received  without  much  comment. 

Concern  was  expressed  that  previous  issues  of  this  standard  will 
not  be  available  to  support  existing  drawings  for  on-going  programs. 
The  attendees  asked  that  ADPA  urge  ASME  to  make  copies  of  ANSI  Y14.5- 
1973  available  to  assist  users  in  interpreting  drawings  prepared 
in  accordance  with  that  issue. 

It  was  pointed  out  that  Appendix  D  of  ANSI  Y14.5M-1982  contains  a 
summary  of  former  practices.  In  addition,  VSMF  maintains 
historical  records  on  microfilm. 

ACTION  ITEM:  Survey  the  continued  need  for  the  1973  issue 
and  submitt  request  to  ASME  as  necessary. 


D.  Source  Control  Drawing  Problems  on  the  MX  Program 

Robert  E.  Hartman  described  problems  (see  Attachment  B)  experienced 
when  prime  contractors  failed  to  support  the  data  package  with 
design  disclosure  package  and  provided  only  source  control  drawings. 
Items  were  new  design  and  program  funded. 

ACTION  ITEM:  Review  requirements  for  drawing  types  to  plug 
loopholes . 


II.  QUESTIONS  and  ANSWERS 


The  questions  generally  fell  into  the  following  groups: 


A.  Format  Problems 

IQ  Is  a  Revision  Status  of  Sheets  block  required  on  Sheet  1 
of  ADPs  prepared  documents  when  all  sheets  carry  the  same 
revision  letter? 

lA  No — it  was  suggested  that  a  note  be  added  stating  "All  sheets 
carry  the  same  revision  letter"  ,  but  this  is  not  required  by 
DOD— STD— 100. 


2Q  ANSI  Y14.1  is  not  clear  as  to  the  requirement  for  the 

supplementary  drawing  number  block  on  continuation  sheets  of 
"A"  size  multiple  sheet  drawings.  Clarify. 

2A  Currently,  the  supplementary  drawing  number  block  is  required 
on  all  continuation  sheets.  There  are,  however,  some  distinct 
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advantages  to  omitting  it  on  continuation  sheets  of  A  size 
drawings. 

ACTION  ITEM:  Develop  proposal  and  request  clarification. 


3Q  How  are  Roman  numerals  handled  on  machine  prepared  drawings  and 
Parts  Lists? 

3A  A  type  font  should  be  used  that  has  serifs  on  upper  case  I's. 
Alternatively,  the  Roman  numeral  may  be  converted  to  Arabic. 
Manual  application  of  serifs  is  not  advocated;  can  be  missed  on 
subsequent  changes.  Clarity  and  consistency  in  the  appli¬ 
cation  is  the  primary  consideration. 


B.  Item  Identification  and  Part  Substitution 

4Q  Is  it  common  to  use  a  significant  drawing  numbering  system 
based  on  part  or  drawing  type? 

4a  A  nonsignificant  numbering  system  is  strongly  recommended. 

This  avoids  numerous  system  problems,  including:  (1)  breakdown 
when  exceptions  become  necessary,  (2)  need  for  part  number  changes 
because  of  drawing  type  change,  and  (3)  numerous  handling  rou¬ 
tines  which  users  sometime  apply  thoughtlessly  just  because  of 
the  number. 


5Q  The  method  of  building  a  part  number  for  bulk  items  needs 

clarification.  Suggest  the  use  of  methods  similar  to  M39014/04- 

0101. 

5 A  Agree. 


ACTION  ITEM:  Will  work  with  logistic  activies  to 
develope  recommendations  for  MIL-STD-490  and  -962. 


NOTE:  ADPA  is  on  record  with  DMSSO  that  such  identifiers 

should  not  exceed  15  digits;  DMSSO  has  agreed. 


6Q  For  part  numbers  such  as  M39003/01-XX-X,  should  the  complete 
MIL  spec  number  be  entered  in  the  Drawing  or  Document 
(Specification)  column  of  Part  Lists? 

6A  To  ensure  procurement  of  MIL-Spec  qualified  items,  the  complete 
specification  numbers  should  be  entered  in  either  the  Document 
Number  column  or  the  Description  column. 
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7Q  Substitute  parts  are  increasing  for  specific  items;  especially 
microcircuits.  Is  there  an  effort  to  add  a  standard  drawing 
example  in  DOD-STD-lOO? 

7 A  No.  Elements  of  this  subject  are  covered  by  MIL-STD-480  and 
MIL-STD-454,  Requirement  7. 

NOTE:  Part  substitution  is  still  a  large  problem  for 

both  Government  and  Industry  which  the  TDD  is  continuing 
to  work  with  several  DoD  agencies. 


8Q  How  are  Manufacturing  options  added/documented  (eg,  riveted 
assembly  versus  welded  assembly)? 

8A  If  the  items  are  true  fit  and  function  equivalents,  separate 
part  numbers  are  recommended  with  an  "or"  condition  called  out 
in  the  Parts  List.  If  one  item  is  preferred  over  the  other, 
the  Parts  List  should  call  out  the  preferred  item  with  a  note 
that  the  other  item(s)  is  an  alternate. 


9 Q  When  accumulation  of  EOs  against  a  drawing  is  permitted,  how 
are  the  EOs  identified;  Method  A  or  B? 

Method  A: 

EO  1,  2,  3,  etc;  incorporate  in  A  change 


EO 

Al, 

A2, 

A3, 

etc; 

incorporate 

in 

B 

change 

Method  B 

l : 

EO 

Al, 

A2 , 

A3, 

etc; 

incorporate 

in 

A 

change 

EO 

Bl, 

B2, 

B3, 

etc; 

incorporate 

in 

B 

change 

9 A  The  EO  identification  system  is  the  contractor's  option  which 
must  be  documented  by  his  proceedures.  Incorporation  of  the 
EOs  always  advances  the  drawing  revision  letter.  The  majority 
of  those  present  who  use  the  EO  identities  described  in  this 
question,  use  Method  A. 


C .  Identification  Marking 

ACTION  ITEM  -  These  questions  identified  the  need  to  review 
the  compatibility  between  MIL-STD-130  and  DOD-STD-lOO. 


10Q  When  is  it  mandatory  to  mark  the  MFR  FSCM  number  on  an  item 
which  design  activity  does  not  produce  themself? 

10A  The  MFR  FSCM  number  is  to  be  marked  on  all  parts  which  could 
qualify  for  spares  provisioning  (eg;  inseparable  assemblies, 
matched  assemblies,  complete  assemblies,  and  detail  items). 
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11Q  When  contract  requires  use  of  customers  format,  is  the  contrac¬ 
tor's  FSCM  number  to  be  marked  as  MFR  on  the  item(s)? 

11A  Yes,  if  the  contractor  does  the  manufacture.  The  customer's 
FSCM  number  prefixes  the  part  number  and  the  appropriate  FSCM 
number  of  the  manufacturer  is  marked  in  accordance  with 
MIL-STD-130. 


12Q  MIL-STD-130  should  clarify  that  vendors  part  number  alone  sat¬ 
isfies  the  marking  requirements  on  specification  control  items. 

12A  This  is  stated  in  DOD-STD-lOO,  paragraphs  201.4.2  and  402. 10. d. 


13Q  If  drawing  revisions  and  Parts  List  revisions  do  not  track, 
which  revision  letter  is  marked  on  the  printed  wiring  board? 

13A  DOD-STD-lOO,  paragraph  402. 6C  states  that  part  numbers  shall 

not  include  drawing  revision  letters.  Revision  letter  marking 
is,  therefore,  not  required  except  when  MIL-STD-1389  is  contrac¬ 
tually  invoked.  In  any  case,  the  drawing  (not  the  PL)  is  the 
controlling  document  which  establishes  the  part  identification. 


D.  Status  of  Applicable  Standards 

14Q  How  are  companies  implementing  ANSI  Y14.5M-1982? 

14 A  Not  many  of  the  organizations  represented  at  the  Workshop  are 
presently  implementing  this  new  standard.  Some  are  training 
personnel  in  the  differences  from  previous  issue. 


15Q  Is  DOD-STD-lOO  drawing  types  changing  to  ANSI? 
15A  Don't  know  as  yet. 


16Q  What  is  the  status  of  Y14.8  casting  standard? 

16A  This  is  still  under  development  in  the  ASME  subcommittee. 


17Q  Will  MIL-STD— 34  "Preparation  of  Drawings  for  Optical  Elements" 
be  updated  or  replaced? 

17A  ANSI  Y14.18  has  been  revised  recently.  It  was  reviewed  by  DoD 
activities  and  considered  not  a  significant  improvement  over 
MIL-STD— 34 .  DOD-STD-lOO  will  continue  to  invoke  MIL-STD-34. 
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18Q  Does  ANSI/ IEEE  Std  268-1982  replace  ASTM  E380-76? 


18 A  No,  not  for  DoD  applications;  see  DOD-STD-lOO ,  Notice  3. 
However,  both  standards  have  DoD  Acceptance  Notices. 


19Q  What  is  the  status  of  HDBK  2000  including  all  the  dash  numbers? 

19A  The  (5  year  plan)  Standarization  Program  Analysis  on  Soldering 
( FSC :  SOLD)  explains  what's  going  on.  Copies  may  be  obtained 
from; 

Naval  Publications  and  Forms  Center 
5801  Tabor  Avenue 
Philadelphia,  PA  19120 


20Q  What  is  the  status  of  MIL-P-50884C  and  proposed  standard 
MIL-STD-2118? 

20A  As  of  83-08-19,  these  documents  were  still  a  "couple  of  months" 
away  from  publication. 


E.  Specification  and  Source  Control  Drawings 

21Q  Should  all  vendors  and  associated  part  numbers  be  added  as 
required  to  specification  control  drawings  in  the  suggested 
Sources  of  Supply  list?  If  not,  what  type  of  "Audit  Trail" 
is  required  to  use  parts  in  hardware? 

2 1A  Inculsion  of  more  than  two  suggested  sources  is  not  required 
by  DOD-STD-lOO.  The  panel  recommended  a  controlled  data  base 
accessable  to  purchasing,  receiving  inspection,  etc,  with 
documented  approval  of  equivalent's. 


22Q  Define  "specialized  segment  of  an  industry"  relative  to  speci¬ 
fication  control  drawings. 

22A  "Specialized  segment  of  an  industry"  is  any  supplier  who  has 
recognize  expertise  in  producing  a  particular  product  line 
(eg;  an  electric  motor  manufacturer,  hydraulic  valve  manu¬ 
facturer,  etc).  These  suppliers  typically  provide  Applications 
Engineering  services  to  tailor  their  product  line  to  specific 
design  requirements.  Such  tailoring  is  usually  provided  at 
significantly  less  cost  than  would  be  incurred  for  new  design 
of  an  equivalent  item. 


23Q  Will  "vendor  item  drawing"  become  a  type  of  control  drawing 
like  specification  and  source  control  drawings? 

23A  "Vendor  item  drawing"  may  replace  "specification  control  drawing". 
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F.  Data  Automation 


24Q  We  have  much  CAD  output  from  Versatek  printers  on  wood  pulp 
paper.  Most  DoD  services  will  not  accept  this.  Why  not? 

24A  Will  not  meet  MIL-M-9868  microfilm  requirements. 


25Q  DARCOM  is  procuring  several  DSREDS  (pronounced  "des-reds") 

systems.  What  is  the  status?  Is  the  technology  sufficiently 
advanced  to  procure  such  an  integrated  system? 

25A  Several  systems  are  planned  (if  funded).  First  system  will  be 
at  Redstone  Arsenal.  RFP  to  be  issued  soon. 


G.  Miscellaneous 


26Q  What  is  the  difference  between  Level  2  and  3  drawings?  Do 
contractors  quote  differently  for  Level  2  or  3? 

26 A  Levels  1,  2,  and,  3  allow  for  a  progression  of  a  program's 
data  packages.  Level  2  and  3  are  per  DOD-STD-lOO  with  no 
lesser  quality  and  depicts  the  engineering  designed  config¬ 
uration.  The  difference  is  the  content  required  to  produc¬ 
tionize  the  limited  or  pre-production  data  (eg;  generate 
drawings  of  harnesses  vs  point-to-point  wiring  lists,  castings 
vs  hog-outs,  etc).  Production  tooling  is  another  consideration. 
The  pre-production  (Level  2)  should  be  assessed  for  tailoring 
(ie,  altering  drawing  requirements  to  accomodate  a  contractor's 
drawing  practices  for  a  limited  build  condition).  A  detailed 
explanation  of  Levels  is  contained  in  the  Appendix  of  DOD-D-IOOO 


27 Q  What  should  we  do  about  unrealistic  requirements  for  test 

coupons  in  MIL-STD-275D?  The  .070  land  defined  by  MIL-STD-275D 
for  Coupon  A  is  not  realistic.  Terminal  lands  for  Coupon  A, 
Layers  1  and  2  should  use  the  smallest  terminal  land  used 
on  the  associated  board. 

27A  Fill  out  a  Form  DD1426  (included  at  the  back  of  most  specs)  and 
send  it  to  the  custodian  of  the  specification  with  a  copy  to 
the  Chairman  of  the  ADPA/TDD  Engineering  Drawing  Section. 
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28Q  In  cable  assembly  drawings,  dimensions  of  actual  cut  wire 

length  are  difficult  to  specify  because  connectors  from  various 
manuf acturers  may  require  different  trim  lengths  prior  to 
assembly.  How  can  this  be  resolved? 

28A  DOD— STD-100  only  requires  end  product  dimensions;  specific  the 
overall  dimensions  (including  the  connectors)  only.  Manufac¬ 
turing  planning  is  then  responsible  for  adjusting  wire  trim 
lengths  to  meet  the  end  product  dimensions  regardless  of  the 
connector  manufacturer. 


29.  The  following  questions  were  not  answered  at  the  workshop: 

a.  Q  Should  off-the-shelf  material  be  documented  using  a 

specification  control  drawing  per  DOD-STD-lOO  or  a 
material  specification  per  MIL.-STD-490? 

Paragraph  402.16.4  of  MIL-STD-100  says  to  not  prepare 
drawings  for  bulk  material  and  paragraphs  1.1  and 
1.4.1  of  MIL-STD-490  infer  that  off  the  shelf  material 
is  outside  of  the  scope  of  -490  specifications. 

ACTION  ITEM:  Develop  proposed  clarif ication. 

NOTE:  DOD-STD-IOOC ,  Notice  2  changed  paragraph 

402.16.4  to  prohibit  preparation  of  drawings  for 
"specific  quantities  of  bulk  materials"  only. 

b.  Q  With  the  trend  toward  using  computer  aided  design  in 

the  generations  of  drawing,  is  there  a  plan  to  update 
DOD— D— 1000  and  DOD-STD-lOO  to  further  define  their 
use. 

A  Detailed  specifications  invoked  by  -100  are  being 
revised  to  accommodate  CAD  prepared  drawings  (see 
section  I,  paragraph  A  of  this  report).  There  are  no 
plans  to  specifically  revise  -100  and  -1000  at  this 
time. 

c.  Q  On  CAD  developed  drawings  data,  what  procedure  is 

used  to  maintain  change  control — hard  copy  or  data¬ 
base  maintenance?  How? 

ACTION  ITEM:  To  be  addressed  by  Ad  Hoc  Committee 
on  Paperless  Data  Requirements. 

d.  Q  How  many  organizations  use  hardware  revision  letter 

part  marking — always,  the  assembly  level  only,  or 
never? 

ACTION  ITEM:  Survey  Engineering  Drawing  Section 
members . 
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ENGINEERING  DRAWINGS  Name  tjjgg  l£i ePhone 

WORKSHOP  12  William  R.  DeWaal  Harry  Diamond  Labs  (202)290-2634 

2800  Powder  Nill  Rd 
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Attachment  B 


SOURCE  CONTROL  DRAWING  PROBLEM 

Presented  by  Robert  E.  Hartiasn 
Por  Engineering  Drawing  Section  Consideration 

®  SOURCE  CONTROL  DRAM 1  MGS  ARE  TO  BE  USED  IN  DOCUMENTING  AN  EXISTING  OFF-THE-SHELF  ITEM 
WHEN  ADDITIONAL  'QUALITY  CONFORMANCE  INSPECTION  AND  APPROVAL'  MUST  BE  IMPOSED  BY  THE 
USER. 

DOD-STD-IOOC 

201.4.3  Source  control  drawing.  A  source  control  drawing  deplete  an 
existing  coamerdal*  or  vendor*  Item  which  exclusively  provides  the  perfor¬ 
mance,  Installation  and  Interchangeable  characteristic*  required  for  one  or 
more  specific  critical  applications.  Quality  conformance  Inspection  and 
approval  procedure  shall  be  stated  on  the  drawing  or  in  a  document 
referenced  on  the  drawing. 


0  SOURCE  CONTROL  DRAWIN6S  ARE  ML  TO  BE  USED  WHEN  DOCUMENTING  A  NEWLY  DESI6NED  ITEM. 


RE-IDENTIFICATION  OF  SUBCONTRACTORS  PART  NO.  BY  USING  A  SOURCE  CONTROL 
DRAWING  CAUSES  VIOLATION  OF  MIL-STD-13Q. 


MH.-STO-130E 

3.9  Identifying  tfamber.  The  number  uaed  to  Identify  an  Item.  It  1*  the 
***ICij  by  the  design  activity  whose  engineering  drawings,  specifi¬ 
cations.  standards,  and  inspection  requirements  control  the  design  of  the 
Item.  This  number  may  be  a  specification,  drawing,  part,  model,  type,  eata- 
log,  etc.,  number  depending  on  the  numbering  system  of  the  design  activity. 
Whenever  a  pert  number  Is  assigned  to  an  Item  of  production,  the  part  number 
assigned  shall  be  or  Include  the  design  activity  drawing  number  and  shall  be 
used  a*  che  identifying  number.  The  identifying  number  shall  contain  the 
design  activity  identification  code  as  a  prefix. 


THE  SUBCONTRACTORS  SET  OF  DOD-D-IOOO,  LEVEL  3,  ENGINEERING  DATA  IS  BEING  PREPARED 
1NC0MPLETE/DEFICIENT  AS  TO  CONTAINING  THE  REQUIRED  PERFORMANCE  DATA. 


DOD-STD-IOOC 
Para  201.4.1 

mote  is  Hi*  tern  -performance  data'  means  a  listing  of  those  physical  and 
functional  characteristic,  under  specified  operating  condition,  (loads,  speeds, 
*tC')  *°d  9ovironmsntal  conditions,  ss  required  to  fully  describe  the  essential 
operating  ch.ract.ri.tic.  under  which  the  lee.  muse  operate  and  perform.  The 
char.cteri.tic.  ao  Hated  shall  be  defined  to  the  degree  that  interchangeability 
of  substitute  item,  produced  by  an,  nanufacturer  1.  assured  If  the  specified  per 
formance  la  possessed  by  these  Items. 


rn!!x!IiIiVra1PR0CUREMEMT  IS  DIFFICULT'  CONFUSING,  AND  COSTLY  WHEN  THE  REQUIREMENTS 
CONTAINED  IN  TWO  SETS  MUST  BE  COMPARED. 

sot"Jo"tMeffecti!Ie.SETS  0F  “ATA ,,  IHE  f0IICE  ,s  cmmm’  m  muaumiiCLm 

DOCUMENTATION  OF  A  NEWLY  DESIGNED/DEVELOPED  ITEM  IS  TO  BE  DOCUMENTED  BY  A  SET  OF 
PERFORMANCE  data1:  5  E"SI"EE*'"6  MTA  P*EPAI,ED  E0"PLETE  »°»-STt-100  WHICH  INCLUDES 
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ENGINEERING  DATA  DEFINITION 


DOD-STD-IOOC 
22  December  1978 

719  Engineering  data.  Engineering  docuaents  euch  as  drawings,  associated 
lists,  accompanying  docuaents,  aanufacturer  specifications,  and  standards,  or 
other  inforaation  prapared  by  a  design  activity  and  relating  to  the  design,  manu¬ 
facture  ,  procureaent,  test,  or  Inspection  of  items  or  services. 


0  BHO-AWC  TAILORED  THE  LAST  SENTENCE:  .  .  PREPARED  BY  THE  ASSOCIATE  CONTRACTOR, 

HIS  SUBCONTRACTORS  AND  VENDORS  REQUIRED  TO  DEFINE  OR  CONTROL  A  SPECIFIC  ENGINEER¬ 
ING  DESIGN  BASELINE.' 

THIS  EFFORT  IS  AN  ATTEMPT  TO  LIMIT  THE  AMOUNT  OF  DATA  REQUIRED  TO  THE  FOLLOWING: 

o  ENGINEERING  DRAWINGS  OF  VARIOUS  TYPES  NECESSARY  TO  DEPICT  THE  PHYSICAL  AND 
FUNCTIONAL  END  ITEM  REQUIREMENTS. 

0  MLI  THOSE  REFERENCED  CONTRACTOR  PECULIAR  SPECIFICATIONS  AND  STANDARDS  THAT 
HAVE  NO  EQUIVALENT  GOVT/ANSI  DOCUMENTS  AND  ARE  UNI QUE/CR IT 1C AL/ESEHT I AL  IN 
DEFINING  THE  ITEM- 

o  JMLI  THOSE  REFERENCED  UNIQUE/CRITICAL/ESSENTIAL  CONTRACTOR  PECULIAR  PRO¬ 
CESSES  AND  PROCEDURES  THAT  WOULD  REQUIRE  ADDITIONAL  DESIGN  EFFORT  BY  A 

.  SECOND  SOURCE  TO  PRODUCE  THE  ITEM  IF  THEY  WERE  NOT  PROVIDED- 

0  REFERENCED  UNIQUE/CRITICAL/ESSENTIAL  TOOLING  DRAWINGS. 

0  VENDOR  DATA  OF  EXISTING  OFF-THE-SHELF  REPARABLE  COMMERICAL  ITEMS  DOWN  TO  THE 
LOWEST  REPARABLE  LEVEL- 

0  ENGINEERING  CHANGE  DOCUMENTS  THAT  HAVE  NOT  BEEN  INCORPORATED  INTO  THE 
ENGINEERING  DATA. 
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CORRECT 


INCORRECT 
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REFERENCED  CONTRACTOR  HOW-TO-DO  TYPE  OF  DOCUMENTS 


o  DOCUMENTS  CONTAINING  NO  DESIGN  OR  END  ITEM  REQUIREMENTS  SHALL  NOT  BE  REFERENCED  AS 
A  DELIVERABLE  DOCUMENT  ON  THE  ENGINEERING  DATA.  (DOD-STD-lOO,  PARA  201-1,  201-1-1, 
AND  DOD-D-IOOO,  PARA  3-3-3,  3-4) 

0  Engineering  Drawings  are  to  be  Interpreted  1AU  DOD-STD-100  and  Ita  eubtler 
docuaenta.  Contractor  peculiar  drafting  rooa  annuals,  productlon/aachlnlng 
guides,  Interpretation  of  dimensioning,  etc.  are  not  to  be  referenced  and 
submitted. 

Note:  These  docuaenta  aay  be  placed  in  parenthesis  and  flagged  to  a 
general  note  stating  'these  documents  are  for  the  (specific 
contractors)  use  only". 


o  A  COMPETITIVE  PROCUREMENT  SET  OF  ENGINEERING  DATA  WILL  NOT  BE  ACCEPTED  IF 
OTHER  CONTRACTORS  MUST  INTERPRET  ANOTHER  CONTRACTORS  PECULIAR  HOW-TO- 
DOCUMENTS 

0  57  COPIES  OF  EVERY  DOCUMENT  REFERENCED  ARE  PREPARED  BY  00-ALC  WHEN  PROCURE¬ 
MENT  FOR  REPLACEMENT  ITEMS  OCCURS-  IT  IS  NOT  COST  EFFECTIVE  FOR  THE  AIR 
FORCE  TO  ACCEPT  AND  MAINTAIN  CONTRACTOR  HOW-TO-DO  DOCUMENTS 


SELECTION  OF  REFERENCED  DOCUMENTS  IAW  HlL-STD-143  (ORDER  OF  PRECEDENCE) 


0  CONTRACTOR  PECULIAR  SPECIFICATIONS/PROCESSES  ARE  NOT  TO  BE  SPECIFIED  INSTEAD  OF 
THE  GOVT/ANSI  DOCUMENT  UNLESS  THE  60VT/ANSI  DOCUMENT  IS  NOT  SUFFICIENT  TO  DISCLOSE 
THE  DESI6N  REQUIREMENT-  (D0D-STD-100  (TAILORED)  PARA  402-18) 

0  THE  SELECTION  MUST  BE  TECHNICALLY  SUITABLE  TO  SATISFY  THE  DESIGN  RE¬ 
QUIREMENTS  IN  EVERY  RESPECT  AND  BE  MOST  ECONOMICAL  TO  THE  GOVERNMENT. 

0  THE  PROVISION  TO  IDENTIFY  THE  CONTRACTORS  DOCUMENTS  THAT  ARE  EQUIVALENT  TO 
THE  GOVT/ANSI  DOCUMENTS  BY  PLACING  THEM  IN  PARENTHESIS  IMMEDIATELY  AFTER  THE 
GOVT/ANSI  NUMBER  WAS  SPECIFIED  TO  ALLOW  THE  CONTRACTOR  NUMBER  TO  BE  READILY 
IDENTIFIED  FOR  THEIR  IN-HOUSE  PRODUCTION- 

o  ACCEPTING  ESSENTIALLY  DUPLICATE  'LIBRARIES'  OF  CONTRACTOR  DOCUMENTS  FROM 
EVERY  CONTRACTOR,  PROLIFERATES  THE  AIR  FORCE  DATA  DEPOSITORY  AND  IS  NOT  COST 
EFFECTIVE. 
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WORKSHOP  #3 


ILS/TECHNICAL  PUBLICATIONS 
MEETING  REPORT 


WORKSHOP  PARAMETERS  -  The  ILS/Technical  Publications  Workshop  was  conducted  from 
1315  to  1700  on  May  24,  1983  in  the  Continental  Room  of  the  Chamberlin  Hotel, 
Hampton ,' Virginia .  This  workshop  was  a  part  of  the  Twenty-Fifth  Annual  Meeting 
of  the  Technical  Documentation  Division,  American  Defense  Preparedness 
Association . 

Workshop  #3  was  attended  by  24  participants  (9  government  and  15  industry 
representatives).  The  roster  identifies  each  participant  by  name  and  affiliation. 

OVERVIEW  -  The  Workshop  Chairman  convened  the  session  by  presenting  a  brief 
report  on  the  status  of  last  years  action  items.  Three  areas  of  follow-up  action 
were  reported : 

The  first  area  involved  assistance  in  the  Technical  Manuals  Specifications 
and  Standards  (TMSS)  program.  The  Program  Plan  for  this  effort  was  approved 
in  January,  1980,  and  this  plan  was  developed  and  coordinated  with  the  DOD 
Components  and  Industry  by  the  U.S.  Army  DARCOM  Material  Readiness  Support 
Activity,  Lexington,  Ky. ,  the  Lead  Service  Activity.  It  was  noted  that  the 
TMSS  Chairman,  Mr.  Art  Rulon  of  DARCOM,  presented  a  TMSS  status  report  at  our 
23rd  Annual  Meeting  held  at  the  U.S.  Air  Force  Academy,  Colorado  Springs,  Colorado 
in  June,  1981.  Mr.  Jim  Richardson  of  DMSSO  provided  current  TMSS  activity 
status  during  the  workshop  discussion.  Further  action  on  TMSS  tasks  is  antici¬ 
pated. 

The  second  area  involved  follow-up  to  the  NAVSEA  Modular  Specification 
System  (M-SPECS).  Mr.  Jim  Richardson  of  DMSSO  provided  current  M-SPECS  activity 
status  durinq  the  workshop  discussion.  Further  action  on  M-SPECS  development 
is  anticipated. 

The  third  area  involved  a  joint  action  with  the  Engineering  Drawing  Section 
of  the  Technical  Documentation  Division.  The  following  recommendation  was 
forwarded  to  DARCOM  in  April,  1981: 
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"The  Engineering  Drawing  Section  urges  that  for  Engineering 
Drawings  used  in  manuals,  lettering  heights  be  specified  in 
dimensional  form  (inch  or  millimeter),  rather  than  by  point 
size.  We  recommend  this  be  accomplished  by  incorporating  the 
dimensional  equivalent  of  point  sizes  shown  in  Figure  3  of 
MIL-M-46849  (either  directly  or  by  reference)." 

We  have  been  advised  that  this  recommendation  has  been  included  in  the  latest 
revision  to  MIL-M-38784.  This  revision  is  dated  16  April  1983  and  is  now 
available  for  distribution  at  the  Naval  Publications  and  Forms  Center,  5801  Tabor 
Avenue,  Philadelphia,  PA  19120  (Telephone  215-697-3321).  Further  follow-up  is 
planned  until  the  revision  is  reviewed. 

Following  the  action  item  coverage,  the  Workshop  Chairman  briefed  the  participants 
on  the  ILS/Technical  Publications  issues  that  surfaced  during  the  two  Executive 
Board  Meetings  (Sept.  '82  Meeting  at  Defense  Depot  Mechanicsburg  ( DDMP ) , 
Mechanicsburgh ,  Pennsylvania  and  Jan.' 83  Meeting  at  Air  Force  Systems  Command 
(ASD),  Wright  Patterson  Air  Force  Base,  Dayton,  Ohio).  Minutes  of  these 
Executive  Board  Meetings  contain  the  details  of  these  issues. 

After  the  introductory  report,  the  purpose  and  operating  procedures  for  the 
workshop  session  were  given.  At  registration,  "Question/Problem"  forms  were 
made  available  to  all  attendees,  and  during  the  General  Membership  Meeting 
(Session  X  on  May  24,  1983),  the  six  ADPA  workshops  and  workshop  chairmen  were 
introduced.  As  a  result  of  this  solicitation,  Workshop  #3  received  three 
"Question/Problem"  forms  that  were  used  as  workshop  issues  for  discussion. 

Three  key  areas  of  ;cern  (Maintenance  Planning,  Publications  Change  Control, 
and  Analog  and  Digital  Servicing  Techniques)  were  also  identified  as  discussion 
subjects.  To  prepare  for  the  discussion,  each  participant  in  Workshop  #3  was 
asked  to  identify  individual  background  information  such  as  name,  affiliation, 
position,  and  brief  sketch  of  applicable  experience.  The  Workshop  Chairman 
then  stressed  that  each  participant  should  contribute  as  an  individual  rather 
than  as  a  representative  of  the  affiliated  company  or  military  service.  Using 
this  approach,  the  workshop  objective  was  established  as  the  resolution  of  the 
"Question/Problem"  issues  and  discussion  of  the  key  areas  of  concern  that  would 
best  serve  American  Defense  Preparedness. 


T-2 


WORKSHOP  ISSUE  1 


APPLICABLE  STANDARD  FOR  LSA/WSESA 


QUESTION : 

DISCUSSION 


RESOLUTION 

WORKSHOP  ISSUE  : 
QUESTION: 

DISCUSSION 


RESOLUTION : 


What  are  we  using  for  the  government  for  Logistic  Support 
Analysis/Weapon  System  Engineering  Support  Analysis,  that 
is,  MIL-STD-1 388  or  MIL-STD-1388A? 

HIGHLIGHTS:  This  question  related  to  activities  in  support 

of  Skill  Performance  Aids  (SPA)  technical  manual  prepara' ; on 
for  an  Army  Weapon  System.  In  the  discussion,  Army  personnel 
noted  that  MIL-STD-1388A  has  not  been  released  and  is 
currently  in  review. 

Continue  to  use  MIL-STD-1 388  and  seek  guidance  on  your 
program  when  MIL-STD-1 388 A  is  released. 

-  CHANGE  BAR  AUTOMATION 

Is  there  today  a  word  processing  system  which  will  handle 
"change  bar"  designations? 

HIGHLIGHTS:  Most  word  processing  systems  on  the  market  today 

feature  a  "wraparound"  feature.  This  does  not  allow  change 
designators  to  remain  in  the  page  margin.  It  is  frustrating 
to  have  the  power  of  video  editing  techniques  for  text 
manipulation  and  then  find  it  necessary  to  have  an  illustrator 
manually  add  the  change  bars. 

Systems  such  as  the  Xerox  Model  9700  Laser  Printer  provide 
for  change  bar  annotation.  Application  to  an  existing  word 
processing  system  must  be  evaluated  as  well  as  compliance 
with  specification  requirements.  The  AIA  Automated 
Technical  Publication  Svmposium  to  be  held  at  the  San  Diego 
Hilton  on  Sept.  13-15,  1983  will  provide  an  excellent 
opportunity  to  explore  other  possibilities. 


WORKSHOP  ISSUE  3 


IMPACT  OF  THREE-LEVEL  MAINTENANCE  CONCEPT 


QUESTION:  What  will  be  the  impact  of  the  new  three-level  maintenance 

concept  on  maintenance  planning,  LSA/LSAR,  and  provisioning? 

DISCUSSION  HIGHLIGHTS :  Ibis  question  was  related  to  Army  consideration  of 

change  from  five-level  to  three-level  maintenance.  Automated 
test  equipment  was  identified  as  the  prime  motivating  factor. 

RESOLUTION:  Converting  from  five-level  to  three-level  maintenance  would 

have  major  impact  on  fielded  systems.  This  impact  could  be 
reduced  significantly  if  the  three-level  maintenance  concept 
were  phased-in  by  limiting  application  to  new  systems. 
Considering  the  tie-in  to  the  introduction  of  automated  test 
equipment,  the  limited  use  of  three-level  maintenance  appears 
to  be  the  practical  way  to  approach  the  problem. 

KEY  AREA  OF  CONCERN  NO.  1  -  MAINTENANCE  PLANNING 

During  the  last  two  decades  emphasis  on  maintenance  planning  has  been  on 
the  increase.  Resources  and  effort  have  been  applied  to  improve  the  Life  Cycle 
Cost  of  DOD  fielded  systems  and  equipment.  Provisioning,  support  equipment, 
training,  and  up-front  analysis  were  the  sub]ects  discussed  in  the  workshop 
with  respect  to  their  impact  on  technical  manuals.  It  was  agreed  that  technical 
manuals  must  provide  the  bridge  between  the  operational  maintenance  personnel 
and  the  fielded  systems  and  equipment.  Use  of  the  technical  manuals  in  the 
training  environment  enhances  their  use  in  subsequent  field  assignments. 

The  discussion  brought  out  the  uniqueness  of  individual  service  missions 
and  requirements,  and  emphasized  the  difficulty  in  applying  maintenance  planning 
across  the  board.  Even  the  nomenclature  developed  by  the  different  branches  of 
.Army,  Navy,  and  Air  Force  tends  to  make  transition  difficult.  Perhaps  this 
explains  the  evasive  goal  of  the  TMSS  effort.  More  must  be  done  to  improve 
and  make  easier  the  application  of  maintenance  planning  across  service  lines  of 
interest . 
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In  the  provisioning  area,  timing  and  configuration  are  critical  elements 
to  consider  to  achieve  good  correlation  of  fielded  equipment,  illustrated  parts 
breakdowns,  and  the  supply  system.  Although  much  progress  has  been  made  to 
improve  this  correlation  there  is  much  room  for  further  innovations. 

By  popular  demand  of  the  workshop  participants,  the  impact  of  automation 
techniques  on  maintenance  planning  was  discussed.  Forward  looking  concepts 
envision  the  up-front  maintenance  planning  documentation  to  be  the  formation 
of  the  technical  manual  data  base.  T^e  thought  here  is  to  progress  to  the 
point  where  the  initial  keystrokes  of  maintenance  planning  can  be  captured  and 
applied  directly  to  technical  manual  preparation.  This  challenge  is  coming 
into  focus  now  but  will  require  much  effort  to  implement. 

KEY  AREA  OF  CONCERN  NO.  2  -  PUBLICATIONS  CHANGE  CONTROL 

Configuration  Management  of  hardware  and  software  has  been  addressed  at 
great  length  and  breadth  in  recent  meetings.  This  workshop  area  was  introduced 
to  discuss  the  related  concept  of  publications  change  control. 

The  true  measure  of  effective  control  is  made  when  the  degree  cf  correlation 
between  the  fielded  systems  and  the  technical  manuals  is  determined  by  the  user. 
Although  validation  and  verification  techniques  at  delivery  time  insure  initial 
compatibility,  field  changes  in  equipment  and  procedures  must  receive  the  same 
emphasis  to  keep  systems  and  technical  manuals  on  track. 

Block  changes,  sequentially  dependent  field  changes,  factory  break-in 
versus  field  changes,  and  timing  of  changes  were  among  the  topics  discussed. 

The  relatively  few  horror  stories  brought  out  in  the  discussion  indicated  that 
the  current  control  appears  to  be  adequate.  Impact  of  new  automation  trends 
must  either  maintain  or  improve  the  present  tracking  controls. 

KEY  AREA  OF  CONCERN  NO.  3  -  ANALOG  AND  DIGITAL  SERVICING  TECHNIQUES 

Modern  weapon  systems  and  equipment  have  quickly  capitalized  on  the 
advantages  provided  by  digital  circuitry.  Although  most  sensors  and  manv 
display  devices  continue  to  utilize  analog  devices,  the  processing,  manipulation 
and  control  of  signals  have  realized  a  dramatic  shift  from  analog  to  digital 
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form.  This  workshop  area  was  introduced  to  consider  the  impact  of  this  basic  , 
change  on  the  technical  manual  requirements. 

Built  in  test  equipment  (BITE),  preventive  maintenance/fault  localization 
(PM/FL),  improved  reliability /maintainability  and  reduced  overhaul  needs  were 
among  the  prime  topics  discussed.  One  irony  that  was  brought  out  was  that 
technical  manual  size  tended  to  increase  to  provide  the  coverage  needed  to 
include  the  self-test  circuitry.  Another  concern  was  the  emphasis  on  line 
drawings  when  digital  circuitry  parts  location  could  be  handled  more  easily 
by  photographic  renderings. 

The  discussion  reached  the  point  where  great  savings  in  Technical  Manual 
effort  would  be  realized  if  BITE,  PM/FL,  and  other  self  test  circuitry  could 
be  brought  to  the  100%  capability  in  the  area  of  servicing  digital  circuitry. 
Current  practice  falls  short  of  the  100%  capability  and  relies  on  Technical 
Manual  coverage  to  complete  the  support.  This  practice  results  in  increased 
Technical  Manual  size  to  cover  the  undisclosed  capability  delta. 

RECOGNITION:  Special  thanks  are  in  order  for  the  excellent  setting  provided 
by  both  Fort  Monroe  and  the  Chamberlin  Hotel. 

Also,  the  attendance  and  active  participation  of  Jim  Richardson, 

Col.  Joseph  W.  Lloyd,  and  Col.  S.F.  Putnam  did  much  to  achieve  the  communication 
level  that  was  realized.  Although  not  established  as  a  formal  panel,  these 
participants  formed  the  backbone  of  the  workshop  session. 


T-6 


I 


WORKSHOP  #3 

ILS/TECHNICAL  PUBLICATIONS 


NAME 

Richard  E.  Knob 
Joseph  G.  Polai 
Robert  J.  Winklareth 
Don  Cleveland 
Roger  Frazier 
Denise  Brady 
Col.S.F.  Putnam 
R.  Woznick 
Joe  Hauck 
Ron  Kiesnosh 
Barbara  Vogel 
Carl  A.  Eschenbach 
Bruce  S.  Malmont 
Michael  D.  Marraffino 
Linus  Glowienka 
SM  Sgt .  Danny  Lewis 
M.A.  (Mike)  Daniels 
Col.  Joseph  W.  Lloyd 
Cathleene  Waddell 
Joy  Viars 
Jean  L.  Harman 
David  G.  Blackstone 
Franklin  Phillips 
Jim  Richardson 


ROSTER 


AFFILIATION 

Sperry  Corporation 

Honeywell 

XMCO,  Inc. 

TAURIO 

NAVPRO  Dallas 
Naval  Ordnance 
Hg.  CECOM  ( DME ) 

TPC ,  Corp . 

Dayton  T.  Brown,  Inc. 
Dayton  T.  Brown,  Inc. 
Honeywell 
LOGICON,  Inc. 

Hq.  DESCOM 
GTE  Systems 
Ken  Cook  Co . 

AFCOLR 

AACI 

DARCOM  -  AUTO  Systems 
Naval  Sea  Systems  Command 
Designers  &  Planners,  Inc. 
Naval  Sea  Systems  Command 
Ingersoll-  Rand  Co. 

Sanders  Assoc. 


DMSSO 


Workshop  #4 

Configuration  Management 
Wednesday,  May  25,  1983  -  1315  Hours 


CHAIRMAN: 


PANEL/ 
MEMBERS : 


SUBJECTS : 


Mr.  Charles  J.  Embrey 
PACER  Systems,  Inc. 

1755  Jefferson  Davis  Rvy 
Arlington,  VA  22202 
Telephone:  703-920-8300 


Mr.  M.  Daniels 

Manager,  Configuration  Management 

Space  Telescope  Institute,  John  Hopkins  University 

Baltimore,  MD  21218 

Mr.  J.  Nast 
NAST  and  Associates 
15171  Lestics  Lane 
Los  Gatos,  California 

Mr .  J .  Remlker 

Chief,  Configuration  Management  Rqmts  &  Identification 

General  Dynamics/Convair  Division 

P.0.  Box  80847 

San  Diego,  CA  92138 

Qi  Requirements  for  Software  Development  (DOD-STD-1679A) 

Questions  and/or  Problems  Posed  by  the  Workshop  Attendees 

Development  of  an  Action  Item  List  for  Unanswered/Unresolved 
Items  to  be  worked  or  during  the  coming  year. 
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WORKSHOP  PURPOSE: 


The  purpose  of  Che  Configuration  Management  Workshop  was  to  utilize  the 
knowledge  gained  by  the  government  and  industry  participants  who  work  with  and 
apply  this  management  discipline  on  a  day-to-day  bais,  and  also  improve 
communications  regarding  CM  matters  between  all  of  Che  attendees.  The 
objective  of  the  workshop  was  to  identify  and  resolve  problems  which  are 
currently  being  experienced  by  the  attendees,  through  questions  and  answers 
posed  by  both  the  panel  and  the  attendees.  Those  problems  which  required 
specification  changes  to  resolve,  or  were  otherwise  too  time-consuming  or 
complex  to  resolve  at  Che  workshop,  were  recorded  as  action  items  and  will  be 
addressed  by  the  CM  committee  during  the  coming  year. 


WORKSHOP  SUMMARY: 

Mr.  Charles  Embrey  opened  the  workshop  and  introduced  the  panel  members. 
The  workshop  attendees  were  provided  with  copies  DOD-STD-1679A,  Subject: 
Software  Development.  There  were  a  number  of  questions  concerning  that 
proposed  revision  which  were  previously  written  and  submitted  to  the  Chairman. 
Those  questions,  plus  comments  &  questions  from  the  attendees  during  the 
course  of  the  workshop  on  1679A  and  related  CM  matters  formed  Che  basis  of  Che 
workshops  activities.  Mr.  Embrey  also  provided  the  workshop  attendees  with  a 
brief  overview  of  the  current  status  of  the  rewrite  of  DOD-480B  and  the  Joint 
DOD  CM  Regulation. 

1.  DOD-STD-1679A  was  discussed  at  some  length  by  the  workshop  attendees,  and 
the  following  significant  points  were  made. 

o  DOD-1679A  was  not  fully  coordinated  with  all  of  the  DOD  users, 

therefore  it  is  questionable  if  it  should  have  been  released  as  a  DoD 
Standard 

o  DID  number  DI-E-2035E  (Configuration  Management  Plan)  included  in 
Section  6  of  1679A.  Current  planning  indicates  chat  DOD  will  take 
corrective  action.  The  attendees  generally  agreed  the  standard 
( 1679A)  as  rewritten,  satifies  the  CM  direction  required  by  a 
contractor,  when  providing  software  deliverables  to  a  DOD  component. 

2.  Configuration  Management  requirements  imposed  on  subcontractors  and 
vendors  were  discussed  by  Che  attendees,  and  the  following  points  were  made. 

o  Most  companies  insert  a  standard  CM  clause  in  a  sub-contract,  which 
can  be  tailored  to  reflect  any  unique  requirements  necessitated  by 
the  specification  on  the  prime  contract. 

o  Vendor  CM  requirements  are  not  included  for  most  "off-the-shelf" 
components. 

o  CM  compliance  audits  of  sub-contractor  and  vendor  facilities  for 

the  most  part,  are  conducted  on  a  random  basis,  with  government  parti¬ 
cipation  only  when  required  by  the  procuring  activity. 
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3.  Engineering  Change  Proposal  (ECP)  processing  times  were  discussed,  and  it 
was  determined  that  if  processing  times  were  to  be  shortened,  it  would 
require  a  concerted  effort  on  the  part  of  the  contractMand  the  procuring 
activities.  Some  of  the  suggested  methods  for  improving  processing  times 
were: 

o  ECPs  not  be  submitted  by  the  contractor  for  approval,  until  all  of  the 
supporting  and  substantiating  data  is  made  available. 

o  ECPs  requested  by  the  procurring  activity  have  funding  identified  and 
committed,  prior  to  final  approval  by  the  Government. 

o  ECPs  currently  in  process  be  reviewed,  and  a  status  report  provided  to 
program  management  at  both  the  procurring  activity  and  contractor, 
which  highlights  the  cause  for  delay  in  the  processing  cycle. 

4.  Configuration  Management  used  in  conjunction  with  Computer  Aided 
Manufacturing  (CAM)  systems,  was  the  subject  of  discussion  among  the 
attendees.  CM  applied  to  CAM  does  not  pose  any  unique  problems,  and  it  is 
currently  being  accomplished  at  a  number  facilities  with  varying  degrees  of 
success. 

5.  Mr.  C.D.  Fisher  (RCA)  Chairman  of  the  DAR  committee  responded  to  a 
question  on  computer  resources,  “if  they  would  be  treated  as  CPCIs?"  for  CM 
purposes.  Mr.  Fisher  provided  the  attendees  with  the  following  excerpt  from  a 
recent  DAR  circular  which  addressed  that  subject. 

Under  "System  Design  Principles'' 

14.  Computer  Resources.  Acquisition  of  computer  resources  for 
application  to,  or  critical  to  the  direct  fulfillment  of,  the  military  or 
intelligence  missions  of  Che  Department  of  Defense  (including  command  and 
control  systems)  will  be  conducted  in  accordance  with  DoD  Directive  5000.29, 
and  managed  within  the  context  of  the  total  system. 

a.  Requirements  for  interfaces  between  computers,  including  data 
communications,  must  be  identified  early  in  the  life  cycle.  Plans  for 
software  development,  standardization,  documentation,  testing,  and  update 
during  deployment  and  operation  require  special  attention. 

b.  Initial  computer  resource  planning  must  be  accomplished  before 
Milestone  I  and  will  be  continued  throughout  the  life  cycle.  Computer 
resources  support  elements  will  be  considered  in  life  cycle  cost  estimates. 

c.  Where  software  costs  are  significant,  acquisition  strategy  will 
implement  "software  first"  concepts,  wherein  software  design  is  reasonably 
firm  prior  to  the  identification  and  selection  of  the  supporting  hardware. 
Program  Managers  will  plan  and  budget  as  needed  for  continuing  development  and 
evoluc1  m  of  software  throughout  the  acquisition  and  operational  phases. 

d.  Computer  hardware  and  software  must  be  specified  and  treated  as 
configuration  items.  Baseline  implementation  guidance  is  contained  in  DoD 
Instruction  5000.19. 
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CONTINUING  ACTION  ITEMS: 

Mr.  C.  Embrey  will  supply  updated  and/or  draft  Joint  DOD  CM  Documents  for 
comment,  as  they  become  available. 


ROSTER  OF  ATTENDEES 


Raymond  J.H.  Beckingham  Frank  E.  Davanerty  Jr. 

Hughes  Helicopters  Inc.  AAI  Corp. 

Building  6  C/68  Baltimore,  MD  21204 

Culver  City,  California  90230  301-628-8433 

213-305-5241 


Ron  Van  Buskirk 
Aerojet  Electro  Systems 
Azusa,  CA 
213-812-2102 

Delcrio  Cameron 
Litton  Data  Systems  Dir. 
Van  Nors 
213-902-4809 

Joe  Cencich 
DETCOM  DSL 
AMC 

313-464-5262 

Lenny  Ciskawski 
The  Boeing  Company 
M/S  8C-53  Box  3999 
Seattle,  WA  98188 
206-392-2680 

Paul  Courtoglaus 
HQ  ESD/ALEC 
Hanscom  AFB 
Bedford,  MA  01730 
617-861-4257 

Bill  DeWael 
Harry  Diamon  Labs 
202-394-2634 

Larry  Dietz 

PM-CAWS 

DRCPM-CWS 

Dover,  N.J.  07801 
201-724-4905 

D.  Dmartman 
Martin  Marietta 
805-735-5458 


Clive  P.  Durase 
Westinghouse  Electric  Co. 
Defense  Electronic  Center 
P.0.  Box  746.  M.S.  T-380 
Baltimore,  MD  21203 
301-767-8722 

William  B.  Eggers 
Naval  ODD  STA 
Indian  Hd,  MD 
301-743-4389 


Bernard  W.  Fatig 
Westinghouse  Electric  Co. 
Defense  Electronics  Center 
P.0.  Box  746  MST  545 
Baltimore,  MD  21203 
301-765-8605 

Lawrence  S.  Feldman 
Marine  Corps, 

Albany ,  GA 
912-439-6466 

C.D.  Fisher 

RCA  Govt  Comm  Systems 

609-338-2008 

Pat  Greenwood 
Hercules  Inc. 

Aerospace  Div. 

P.0.  Box  98 
Magna,  Utah  84044 
801-250-5911 

Tom  Griffin 
ASD/XRJ ,  W-PAFB ,  OH 
513-255-5632 
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Jean  L.  Hannan 

Naval  Sea  Systems  Command 

DEA  55Z3 ,  Dept  of  Navy 

Washington,  D.C.  20362 

202-692-0160 


Bob  First 

MSD,  Honeywell  Inc. 
5303  Shishale  Ave  N.W. 
Seattle,  WA  98107 
206-789-2000 


Robert  E.  Hartman 

TRW/BMO 

714-382-5941 

Dick  Heggen 
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WORKSHOP  #5  -  COMPUTER  SOFTWARE 


Chairman:  Mr.  Jack  Cooper 

C.A.C.I.,  Inc.  -  Federal 


GENERAL.  Workshop  Session  #5  addressed  the  question  of 
"how  do  we  get  Government  acceptance  of  automated  computer 
program  documentation?"  The  industry  is  increasingly 
utilizing  their  internal  computer  facilities  and/or  word 
processing  systems  for  the  development  and  storage  of,  not 
only  computer  program  documentation,  but  all  engineering  data 
required  by  Government  contracts.  It  would  be  much  more 
cost  effective  if  the  Government  would  accept  for  delivery 
the  engineering  data  in  its  electronic  form  rather  than  on 
paper.  This  Workshop  Session  approached  this  question  from 
the  perspective  of  the  Government  customer. 


DISCUSSION .  Since  the  Department  of  Defense  is  basically 
a  single  customer  served  by  an  extremely  wide  variety  of 
suppliers  utilizing  an  extremely  wide  variety  of  internal 
electronic  systems,  it  became  obvious  that  the  first  require¬ 
ment  for  Government  acceptance  of  electronically  transmitted 
engineering  data  was  some  form  of  standardization.  The  most 
appropriate  form  of  standardization  for  purposes  of 
contractual  requirements  is  a  Military  Standard.  Thus,  it 
was  the  panel's  recommendation  that  a  Military  Standard  on 
the  subject  of  electronic  data  transfer  be  promulgated. 

The  following  is  a  list  of  items  recommended  for  consider¬ 
ation  in  developing  such  a  Standard: 

a.  The  panel  considered  the  various  media  available  for 
transfer  of  engineering  data.  An  assessment  of  the 
current  state-of-the-art  in  Electronic  Mail  transfer 
systems  indicated  that  it  would  be  counter  productive 
to  seriously  consider  magnetic  tape,  disk,  or  diskettes 
as  a  media  for  transfer  of  engineering  data.  It  is 
clearly  within  the  current  state-of-the-art  to  skip 
these  types  of  media  and  go  directly  to  the  electronic 
transmission  of  the  data  via  any  of  the  many  facilities 
currently  available.  It  was  the  panel's  recommendation 
that  the  Standard  only  include  electronic  transmission. 

b:  The  Standard  must  provide  for  independence  of  the 

following  elements: 

1 )  Hardware  -  Since  the  industry  is  using  an 

extremely  wide  variety  of  systems  for  the  development 
and  maintenance  of  engineering  data,  a  successful 
Standard  must  be  independent  of  the  hardware  on  which 
the  data  is  generated.  Also,  since  the  Standard  will 
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be  hardware  independent,  the  engineering  data  will 
be  instantly  useful  to  the  Government  customer 
regardless  of  the  equipment  that  he  is  using. 

2)  Storage  Media  -  Once  again,  the  industry  and  the 
Government  are  both  using  the  entire  spectrum  of 
electronic  media  for  storage  of  data.  Therefore,  a 
successful  Standard  cannot  be  limited  to  any  type  of 
storage  media. 

3)  Transmission  Media  -  The  Standard  must  be 
independent  of  the  medium  to  be  used  for  transferring 
the  engineering  data  electronically,  whether  it  is 
via  satellite  or  via  RS-232  over  the  telephone. 

4)  Engineering  Methodology  -  The  Standard  must  not, 
either  directly  or  indirectly,  limit  a  contractor  in 
his  selection  of  engineering  methodology  to  be  used 
in  producing  his  deliverables. 

5)  Internal  Representation  -  The  transfer  of  electronic 
data  should  be  independent  of  the  form  in  which  the 
data  is  represented  within  any  machine. 

6)  External  Format  -  The  transfer  of  electronic  data 
should  be  independent  of  the  format  in  which  the 
data  is  transmitted.  The  consequence  of  this  item 
is  that  there  will  be  no  impact  on  current  Data  Item 
Descriptions.  The  output  engineering  data  can  be 
formatted  according  to  any  DID  specified  in  the 
contract . 

c.  The  panel  felt  that  it  would  probably  be  beneficial  if 
the  Standard  specified  some  standard  type  of  header  for 
the  data  to  be  transferred  to  facilitate  decoding  by  the 
Government  customer. 

d.  The  subject  of  security  should  be  addressed  in  order  that 
classified  data  could  be  transmitted  when  ever  necessary. 

e.  In  order  to  minimize  the  potential  for  incompatibility 
in  an  electronic  data  transfer,  it  is  recommended  that 
the  subject  of  standard  character  and  graphic  sets  be 
addressed  for  inclusion  in  the  Standard. 

f.  Any  Standard  to  be  successful  must  provide  for  an 
electronic  data  transfer  that  is  verifiable  by  the 
Government  customer. 

g.  The  Military  Standard  must  not  contain  any  provisions 
that  would  limit  or,  in  any  other  way,  bias  the  field  of 
competition. 
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A  MIL-STD  alone  is  not  sufficient  to  bring  about  the  change 
in  the  form  of  engineering  data  for  delivery.  The  panel 
felt  strongly  that  Data  Management  policy  needs  to  be 
promulgated  from  the  OSD  level  that  addresses  this  subject 
area  and  includes  direction  for  the  use  of  the  MIL-STD.  The 
entire  acquisition  community  should  be  provided  guidance  in 
making  the  transition  from  paper  to  electronic  data  delivery. 
The  following  topics  are  recommended  for  consideration  in 
developing  and  promulgating  this  needed  policy  directive: 

a.  The  MIL-STD  should  start  out  as  a  tri-service  standard. 
History  has  taught  us  that  once  the  individual  services 
have  established  policy  of  their  own  it  is  much  more 
difficult,  if  not  impossible,  for  them  to  concur  on  and 
then  change  to  a  unified  standard. 

b.  The  policy  should  provide  guidance  on  "optional"  vs 
"mandatory"  use  of  the  MIL-STD. 

c.  A  transitional  period  should  be  provided  where  in  both 
forms  of  deliveries  are  acceptable  until  such  time  that 
the  new  approach  is  completely  in  place. 

d.  When  items  are  procured  "off-the-shelf"  or  from 
"commercially  available"  inventory,  the  policy  should 
provide  for  delivery  of  the  supporting  data  in  its 
existing  form  (as  long  as  that  data  is  acceptable). 

e.  The  policy  should  provide  for  a  "paperless"  validation 
scheme . 

f.  All  other  elements  of  the  acquisition  system  should  be 
advised  to  take  into  account  the  impact  on  their  areas 
brought  about  by  the  introduction  of  electronic  data 
delivery.  For  example,  the  review  and  audit  of  a  system 
design  will  necessarily  take  place  utilizing  video 
terminals  rather  than  by  persuing  documents. 


Since  the  technology  and  the  practice  are  both  already  in 
use  today,  the  panel  believed  that  the  sooner  electronic  data 
transfers  were  provided,  the  more  cost  effective  it  would 
be  for  Government  and  industry  alike.  Consequently,  the 
panel  recommends  that  this  panel  summary  report  be  provided 
to  the  appropriate  points  of  contact  within  the  DOD. 
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Workshop  #6  -  Engineering  Data  Automation 


Attendance  -  Per  Attached 

The  participants  included  representatives  from  the  three  major  services, 

Office  of  the  Under  Secretary  of  Defense,  DLA  and  Capital  Hill.  The  ratio  of 
70%  Industry  and  30%  Government  was  most  effective  in  reviewing  the  require¬ 
ments  of  the  Government  versus  Industry  capabilities.  The  four  topics 
furnished  by  the  chairman  for  discussion  were: 

1.  Automated  Contract  Reporting  -  Problems  4  Issues 

2.  Automation  of  Technical  Requirements 

3.  Automation  of  Procurement  Documentation 

4.  Automated  Technical  Documentation 

Mr.  B.C.  Lazorchak  then  led  a  discussion  on  pointing  and  proffered  some 
excellent  points  that  need  to  be  addressed  in  automation  of  documentation. 

The  points  discussed  were: 

1.  In  an  integrated  system,  each  -  ility  has  to  forget  his  specific 
role  and  cross  functional  boundaries  to  ensure  success. 

2.  An  overall  plan  needs  to  be  developed  to  account  for  all  the  poten¬ 
tial  functions  for  automation. 

3.  Leave  the  computer  literacy  to  the  systems  analysts  and  rely  on  your 
knowledge  of  the  technical  data  world. 

4.  Stress  and  ensure  hardware  independence. 

5.  An  audit  is  needed  on  cost  savings  as  a  result  of  implementing  the 
systems. 

6.  ADPA  can  "lean-on"  the  JCP  for  expertise  in  printing  questions. 

The  following  questions  were  presented  by  members  of  the  workshop  to  Mr. 
Lazorchak: 

Q.  Who  is  responsible  for  interface  (between  systems  -  between  systems  and 
field  users)? 

A.  No  one  at  this  time. 

Q.  There  are  problems  with  the  computer/and  operating  system)  itself. 

A.  That  is  the  precise  point;  we  have  to  avoid  machine  dependence. 

Q.  Shouldn't  the  Government  develop  a  plan  for  the  data  base? 

A.  Communication  is  needed  first.  Have  to  have  the  big  picture  as  to  cost 

of  conversion,  etc. 

Q.  Some  contractors  are  trying  to  plan  now  for  eventual  digital  delivery  to 
the  Government  but  where  are  the  needed  standards? 
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A.  The  ANSI  X  3  Committee  is  working  in  the  standard  area;  however,  ANSI  is 
too  far  away  and  technology  is  moving  too  fast. 

A  discussion  followed  concerning  the  computer  machine  language  incompatibil¬ 
ity.  During  the  past  year  increased  emphasis  is  being  placed  on  interactive 
accessing  of  contractor  data  bases.  NATO  vendors  and  governments  are  in¬ 
creasing  the  independence  on  it.  Mr.  Lazorchak  mentioned  a  common  data 
dictionary  is  now  being  used  on  the  (Capital)  Hill.  Mr.  Robert  Rhodes, 
Lockheed  Space  and  Missiles,  accepted  chairmanship  of  an  ad  hoc  committee  to 
determine  what  is  needed  in  a  data  dictionary.  He  will  report  at  the  next 
meeting  his  finding;  however,  he  will  accept  any  help  offered. 

Col.  Kuster,  USAF/ASO,  advised  the  panel  that  three  major  AF  acquisitions  are 
currently  allowing  the  AF  to  interrogate  the  contractors  management  data  base 
on  a  real  time  basis.  Our  uniqueness  is  that  the  contractor  is  furnishing  the 
AF  the  interrogating  terminal  to  ensure  compatibility.  This  led  into  the  next 
effort  to  be  undertaken  by  the  panel:  the  development  of  a  uniform  "Statement 
of  Work"  language  that  would  allow  the  Government  to  real  time  interrogate  a 
contractor's  management  data  base  and  thereby  eliminate  the  reams  of  paper 
furnished  the  Government  monthly  for  contract  management.  Mr.  John  Endicott, 
GD/Convair,  accepted  chairmanship  of  an  ad  hoc  committee  to  develop  a  uniform 
SOW  clause. 

A  third  ad  hoc  committee  was  established  and  is  chaired  by  A1  Turino, 
GTE/Sylvania.  A1  has  spent  much  time  with  compugraphics  and  other  graphics 
concerns  to  tag  and  get  the  computers  to  communicate  with  each  other.  The 
thrust  of  his  committee  is  to  define  data  base  requirements  for  graphics  and 
manufacturing  applications  and  associated  integrated  communications. 

A  final  question  presented  to  Mr.  James  D.  Richardson,  DMSSO,  concerned  what 
DoD  was  doing  about  automation  in  addition  to  those  discussed  by  the  DoD  panel 
earlier  in  the  day.  He  cited  four  Navy  programs: 

.  NT I PS 

.  Automation  of  NPFC  -  NPODs  goes  to  RFP  in  30  days 
.  NATSF  -  EDMKS 

.  NAVSEA  -  Automating  three  depositories 
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BEDFORD  MA  01730 


JOHN  D.  COOPER 
CACI,  INC. 

1700  N.  MOORE  ST. 

PH  FLOOR  „„„„„ 

ARLINGTON  VA  22209 


WILLIAM  M  DRUM 
QUALITY  ASSURANCE  OFFICE 
APPLIED  TECHNOLOGY  LAB 
USARTL  <  AVR ADCOM ) 

FT  EUSTIS  VA  23604 


MARTIN  MARIETTA  AEROSPACE 
BALTIMORE  DIVISION 
103  CHESAPEAKE  PARK  PLAZA 
BALTIMORE  MD  21220 


CLIVE  R  DUROSE 

WESTINGHOUSE  ELECTRIC 

SUPR  ENGR 

1469  JUSTIN  PL 

CROFTON  MD  21114 


G  B  COPE 

123  DUNCANNON  ROAD,  GLENWOOD 
BEL  AIR  MD  21014 


PAUL  T  COURTOGLOUS 
ESD/AFSC 

y§f^T0?S'  hanscom  AFB 

ScnI£«kCSNFI®  DATA  MGMT  DI< 
BEDFORD  MA  01731 


JOHN  M  EBERSOLE 
IBM  FEDERAL  SYSTEMS  DIV 
STANDARDS  ADMINISTRATOR 
18100  FREDERICK  PIKE 
GAITHERSBURG  MD  20879 


X-2 


I 


PHILLIP  W.  EDENFIELD 
US  AIR  FORCE 
DATA  MANAGER 
344  OHIO  AVE. 
VALPARAISO  FL 


32580 


WILLIAM  B  EGGERS 

NAVAL  ORDNANCE  STA 

5243A  TECH  DOC  DIV 

NAVAL  ORDNANCE  STATION  61 21 A 

INDIAN  HEAD  MD  20640 


ROY  S.  EMBERLAND 
LITTON  G/CSD 
MGR.  CONFIG.  MGMT. 
5500  CANOGA  AVE. 
WOOKLAND  HILLS  CA 


91364 


CHARLES  J.  EMBREY 
PACER  SYSTEMS,  INC. 

1755  JEFF  DAVIS  HWY  #510 
ARLINGTON  VA  22202 

JOHN  E  ENDICOTT 
GENERAL  DYNAMICS/CONVAIR 
MS  32-6290 

PO  BOX  80S47  ..... 

SAN  DIEGO  CA  92112 

CARL  A  ESCHENBACH 
PO  BOX  85158 

4010  SORRENTOR  VALLEY  BLVD 
SAN  DIEGO  CA  92138 


BERNARD  W  FATIG 
520  BTEWART  AVENUE 
GLEN  BURN IE  MD 


21060 


LAWRENCE  S  FELDMAN 
USMC  LOGISTICS  SUPPORT  BASE 
TECHNICAL  OPERATIONS  DIV 
P840 

ALBANY  GA  31704 


MR  CHARLES  D  FISHER 
RCA 

GOVT  COMM  SYS 
BUILDING  10-6-2 
CAMDEN  NJ 


08102 


ROGER  F.  FISSETTE 
GTE  PRODUCTS  CORP. 

MANAGER,  TECHNICAL  WRITING 
77  A  STREET  ..... 

NEEDHAM  MA  02194 


LTC  NORMAN  FLEIG 
US  AIR  FORCE 
AFCOLR/MS 
WPAFB  OH 


ROGER  P  FRAZIER 
VOUGHT  CORP  „  ___ 

DATA  MANAGER  NAV  PLNT  REP  OFC 
PO  BOX  225907 

DALLAS  TX  75265 

VICTOR  FREDETTE,  JR 
US  NAVAL  ORDNANCE  STA 
CODE  5121 IK 

INDIAN  HEAD  MD  20640 


OTTO  F.  GARRETT 
INTERNATIONAL  LASER  SYST. 
DESIGN  SUPPORT  MANAGER 
3404  N.  ORANGE  BLOSSOM  TRAIL 
ORLANDO  FL  32804 


EDMUND  M  GENDRON 
SMITH  &  WESSON 
MGR  ENGR  SERVICES 
3100  ROOSEVELT  AVE 
SPRINGFIELD  MA 

DANNY  L.  GILLIAM 
ROCKWELL  INT'L 
DATA  MANAGER 
3200  E  RENNER  RD.  , 
RICHARDSON  TX 


01104 


CS-7 

75081 


MR  LINUS  L  GLOWIENKA 

KEN  COOK  COMPANY 

9929  WEST  SILVER  SPRING  ROAD 

MILWAUKEE  WI  53225 


MR  THEODORE  L  GOLMIS 
HUGHES  AIRCRAFT  CO 
BLDG  604  M/S  F— 122 
P  0.  BOX  3310 
FULLERTON  CA 


92634 


MICHAEL  J.  GOY 
USAF 

SR. ,  EQUIP.  SPECIALIST 
FEDERAL  CENTER  , 

BATTLE  CREEK  MI  49016 


JEROME  GRAY 
RT  2  BOX  79V 
PISGAH  MD 


20640 


45433 


PAT  GREENWOOD 
HERCULES  INC 

ENGRNG  ASST  CONFIG  MGMNT 
PO  BOX  98 

MAGNA  UT  84044 

THOMAS  J.  GRIFFIN 
US  AIR  FORCE 

CONFIGURATION  MANAGEMENT  OFCR 
ASD/XRJ 

WPAFB  OH  45433 


KEITH  E  FOSTER 
RAYTHEON  COMPANY 
C/DM  MANAGER 
HARTWELL  AVENUE 
BEDFORD  MA 


01730 


MICHAEL  A.  HALVERSON 
TEXAS  INSTRUMENTS  INC. 
ELECTRO-OPTICS  DIV.  DATA  MGT 
1922  BAYLOR  DR. 

RICHARDSON  TX  7508 1 


JEAN  HARMAN 
NAVSEA 

DIV.  DIR.  SPECS. 
SEA55Z3 
WASHINGTON  DC 


&  STDZN  PROG. 
20362 


RAYMOND  L  JONES 
NAVAL  EOD  FACILITY 
MECHANICAL  ENGINEERING  TECH 
INDIAN  HEAD  MD  20640 


JOHN  R  HART 

BOEING  AEROSPACE  COMPANY 
P 0  BOX  3999 
M/S  8K-61 

SEATTLE  WA  98124 


ROGER  JONES 
NSWSES 

DEPUTY  DEPARTMENT  MGR. 

CODE  0610 

PORT  HUENEME  CA  93043 


ROBERT  E  HARTMAN 
TRW 

CONFIG  CONTROL  ENGR 

PO  BOX  1310 

SAN  BERNARDINO  CA 


92402 


STEVEN  R  KAUFFMAN 

engrLtech  STA  INDIAN  HEAD 
CODE  5222F 

INDIAN  HEAD  MD  20640 


MELVIN  S  HASTINGS 
WESTINGHOUSE  ELECT  CORP 
P  0  BOX  1488 

ANNAPOLIS  MD  21404 


JOE  HAUCK 

DAYTON  T  BROWN  INC 
SALES  &  MKTG  MGR 
CHURCH  ST 
BOHEMIA  NY 


11716 


R.  B.  HEGGEM 

WESTINGHOUSE  ELECTRIC  CORP. 
CONFIG  MGMT  ANALYST 
HENDY  AVE.  ,  BLDG.  21-13 
SUNNYVALE  CA  94088 


WILLIAM  J  HEIM 

ENGR  DATA  MGT  SPECIALIST 

US  NAVY 

NAVAL  WEAPONS  CENTER  3651 
CHINA  LAKE  CA  93535 


THOMAS  J  HENDERSON 
FORD  AEROSPACE  &  COMM  CORP 
BUSINESS  DESIGN  SPECIALIST 
3939  FABIAN  WAY  MS  A45 
PALO  ALTO  CA  94303 


JAMES  R  KAY 
SHILEY  SCIENTIFIC  INC 
SUPERVISOR  DOCUMENT  CONTROL 
17600  GILLETTE  AVENUE 
IRVINE  CA  92714 


JOHN  KICAK 
US  ARMY  DARCOM 
DRCMT-S 

3001  EISENHOWER  AVENUE 
ALEXANDRIA  VA  22333 


RON  KIESNOSKI 
DAYTON  TO  BROWN 
SALES  MGR 
CHURCH  ST 

BOHEMIA  NY  11716 


WILLIAM  KNIGHT 
AEROJET  ELECTRO  SYSTEMS 
SUPERVISOR,  CONFIGURATION  MGMT 
1100  W  HOLLYVALE  ST.  ,  160/4351 

AZUSA  CA  91702 


GEORGE  J.  HROMNAK 
HQ.  ARRADCOMN,  DEPT.  OF  ARMY 
CH.  TECH.  DATA  CONFIG  MGMT  DIV 
DRDAR-TST 

DOVER  NJ  07801 


RICHARD  E  KNOB 

SPERRY  RAND  CORP 

SPERRY  GYROSCOPE  DIV 

3311  AUSTIN  AVE 

WANTAGH  NY  11793 


CAP7  NELSON  P.  JACKSON 
USN,  RET  ADPA 
SUITE  900 

1700  NORTH  MOORE  STREET 
ROSSLYN  VA  2220 


ISACC  JOHNSON 

GTE  PRODUCTS  CORPORATION 

99  A  STREET 

NEEDHAM  MA  02194 


RICHARD  K.  JOHNSON 

TALLEY  OF  ARIZONA 

MANAGER  CONFIGURATION  MGMT 

4331  E.  MCKELLIPS 

MESA  AZ  83208 


WILLIAM  KUSHNER 
MCLAUGHLIN  RESEARCH  CORP. 
DATA  MANAGER 
3200  EISENHOWER  AVE. 
ALEXANDRIA  VA  22304 


COL  WALKER  A.  LARIMER  USAF 
DEF  MAT  SPEC  &  STANDARDS 
DIRECTOR 

TWD  SKYLINE  PLACE  SUITE  1403 
FALLS  CHURCH  VA  22041 


X-  4 


JOHN  A  LASCO 
□PACE  DIV/AFSC 

3D/AQM  WORLDWAY  POSTAL  CENTER 
=  0  BOX  92960 

l.OS  ANGELES  CA  90009 


I 


BERNARD  LAZORCHAK 

jointNcomm!ttee  on  printing 
RM  ST 4  US  CAPITOL  _._in 

WASHINGTON  DC  20510 

CARL.  X  LEWIS 

gKIR?kolkIS5RlSmSiSTRATDR 


SMSGT.  DANNY  LEWIS 
US  AIR  FORCE 
AFCOLR/MS 
WPAFB  OH 


45433 


GEORGE  L.  LEWIS 

NORTHROP  CORPORATION 

MGR. #  CONTRACT  DATA  REST'S 

15150  MAGNOLIA  #270 

WESTMINSTER  CA  92683 

ROBERT  D  LINT 
HONEYWELL  MARINE  OPS 
SR  DATA  MGMT  ANALYST 
5303  SHILSHOLE  AVENUE  NW 
SEATTLE  WA  9S107 


COL.  JOSEPH  LLOYD 
US  ARMY  DARCQM 
6946  COTTONTAIL  CT. 
SPRINGFIELD  VA 


22153 


GEORGE  MAEDA 

AEROJET  ELECTRQSYSTEMS 

ELEC  DSGN  8,  DRFT  SPV  DEPT  4353 

BLDG  194  1100  W  HQLLYVALE  AVE 

AZUSA  CA  71702 


REED  MAGNESS 
DEPT  OF  ARMY 
PHYSICAL  SCIENCE  ADM 
DRDAR— CLT-I 
APG  MD 


21010 


A  W  MAGNUSSON  _  „  „„„ 

WESTINGHOUSE  ELECTRIC  CORP 
SENIOR  DESIGN  ENG 
HENDY  AVE  BLDG  21-13 
SUNNYVALE  CA  95124 


SANDRA  L  MARKMAN 

MARTIN  MARIETTA  AEROSPACE 

CHIEF  TECH  REQU/DOCUMENTATON 

PO  BOX  1681  M/S  CM111 

VAFB  CA  93437 

BEN  H.  MARSHALL 
VOUGHT  CORP. 

SPEC /DATA  ENGINEERING  SPEC 
P.  0.  BOX  225907.  MS  194-23 
DALLAS  TX  75265 

CHARLES  H.  MARSHALL 
HQ  USAF/DCS 
ACQUISITION 


JAMES  R  MCGREGOR 
NSWSES 

ASST  FOR  TECH  OPS 
CODE  4304C 
PORT  HUENEME  CA 

RICHARD  J.  MERSCH 
USA.  MERADCOM 
GENERAL  ENGINEER 
DRDME-DE 
FORT  BEL VOIR  VA 


93043 


22060 


JAMES  A  MILLER 
LOCKHEED  CALIF  CO 
MGMT  SYS  ENG  COORDINATOR 
PO  BOX  551 

BURBANK  CA  91520 

GLEN  E  MOORE 
AEROJET  ELECTRO  SYS  CO 
ASSOC  PROG  MGR  DEPT  3221 
BLDG  59  1100  W  HOLLYVALE  ST 

AZUSA  CA  91702 


JACK  Z.  MOORE 
VSE  CORPORATION 
VICE  PRESIDENT 
2550  HUNTINGTON  AVE. 
ALEXANDRIA  VA 


22303 


VINCENT  J  MORAVEK 
MARTIN  MARIETTA  AEROSPACE 
CHIEF,  DESIGN  SUPPORT 
PO  BOX  179 

DENVER  CO  80201 


J  M  MOT IS 

LOCKHEED  MSLS  &  SPC  CO 
LOCKHEED gM ISSUES  &  SPACE  CO 

SUNNYVALE  CA  94086 


RICHARD  A.  NAPIER 
ROCKWELL  INT'L-CCSD 
MGR.  MECH.  STDS.  &  DRAFTING 
3200  E.  RENMER  RD.  CS7  120-137 
RICHARDSON  TX  75081 

MCDONNELL  DOUGLAS  CORPORATION 
DEPT  201  BLDG  33  ROOM  571 
P  0  BOX  516 

ST  LOUIS  MO  63166 


V  A  NESS 
VOUGHT  CORP 
P  0  BOX  225907 
DALLAS  TX 


75265 


PHILLIP  R.  PARKER 
INTERNATIONAL  DESIGN  &  MFG. 
DIRECTOR,  CONTRACT  ADMIN. 
2305-C  S  RIDGEWOOD  AVE. 
EDGEWATER  FL  32032 


WASHINGTON  DC 


20330 


ANDREW  PEREZ 

PROGRAM0 C ONF I GUR AT I ON  CO-ORD. 
CROCKER  HILL  ROAD  -„02 

BINGHAMTON  NY  13902 


FRANK  PHILLIPS 
SANDERS  ASSOC 
MGR.  ENG.  WRITING 
95  CANAL  ST.  -  NAM3-4 
NASHUA  NH 


03061 


ROCKWELL  INtIrNATIONAL 
ROCKETDYNE  DIV.  CONF  &  DATA  MG 
6633  CANOGA  AVE.  „-,304 

CANOGA  PARK  CA  9e.30A 

JOSEPH  G  POL- A I 

DEVELOPMENT  ENGINEER  ^ 

miokk ST  NE  "s  ”N»3ir° 


W  SCOTT  POLL AND.  JR  . 
SYLVANIA  SYSTEMS  GROUP 
DIVISION  data  MGR 
PO  BOX  7188  MS  6209  _ 

MOUNTAIN  VIEW  CA  94039 


COL.  SIDNEY  F.  PUTNAM 
CMDR.  .  USA  CECOM 
ATTN:  DRSEL-ME 
FT.  MONMOUTH  NJ  07703 


OSWALD  ROGERS 

DATA 1 MANAGEMENT / C  ONF I GUR  AT I ON 


ASD/YYCD 
WPAFB  OH 


45433 


WALLACE  E  ROOK 
CERBERONICS  INC 
5600  COLUMBIA  PIKE 
RAILEY'S  CRSRDS  VA 


22041 


ANTHONY  ROSS.  JR 
US  ARMY  TANK  AUTOMOTIVE  CMD. 
MECH.  ENGINEERING  TECH. 
DRSTA-GSTM 

WARREN  MI  48093 


HAL  E.  ROWLAND 

SUNDSTRAND  AVIATION  OPERATIONS 
CONTRACT  DATA  MANAGER 
4747  HARRISON  AVENUE 
ROCKFORD  IL  61101 


J.  W.  SAUL 
HARRIS  CORP. 

CONFIGURATION  MANAGER 

P.  0.  BOX  92000 

MELBOURNE  FL  32901 


CAPT.  JACK  0.  SAWDY 
US  AIR  FORCE 

AEROSPACE  ENGR.  ,  DESIGN  ic  ANAL 
AFWAL/FIB 

WPAFB  OH  45433 


NORMAN  RADITZ 
NAVAL  AIR  ENGINEERING 
GENERAL  ENGINEER 
LAKEHURST  NJ 


CENTER 

08733 


MR  JAMES  REMIKER 
GENERAL  DYNAMICS/CONVAIR 
MS  22-6180 
PO  80847 

SAN  DIEGO  CA  92138 


ROBERT  D  RHODES 
LOCKHEED  MSLES  & 
B/  102  0/50-13 
P.  O.  BOX  504 
SUNNVALE  CA 


SPACE  CO. 


94088 


SAM  L  RICE 

HQ.  US  ARMY  ARRCOM 

DATA  MANAGEMENT  SPEC, 

DRSAR-LET-C  ,,  t 

ROCK  ISLAND  ARN  IL  61299 


ELLWOOD  H.  RICHARDSON 
MARTIN  MARIETTA  AEROSPACE 
SUPERVISOR.  ENGR.  PROCEDURES 
P  0.  BOX  179.  MN  0438 
DENVER  CO  80201 


MR  BURTON  G  SCHAEFER 
PITNEY  BOWES 

BUSINESS  SYSTEMS  ENGINEERING 
380  MAIN  ST  PO  BOX  6050 
NORWALK  CT  06852 


VINCENT  J  SCHENO 
US  ARMY  ARRADCOM 
CHIEF  CAD-TD/CM  BRANCH 
DRDAR-TSC-E  „ 

.nronCCU  DI5  MTi  21010 


RONALD  J.  SCHRAGE 
US  AIR  FORCE 
DATA  MANAGEMENT  OFFICER 
ASD/XRJ 

WPAFB  OH  45433 


EMERSONS|lECTRIC  COMPANY 
MANAGER  STANDARDS  8<  procedures 
8100  W  FLORISSANT  AVENUE  2624 
ST  LOUIS  MO  63136 


I  SHAPIRO 

H  D  LABS 

DELHD— IT-EA 

2800  POWDER  MILL  ROAD 

ADELPHI  MD  20783 


BRUCE  C  R INKER 

686  AUGUSTA  DRIVE 

FAIRBORN  OH  45324 


I 


GERALD  D.  SHOCK 
NAVAL  EOD  TECH.  CTR. 
GENERAL  MANAGER 
CODE  451 
INDIAN  HEAD  MD 


20640 


WILLIAM  W  THOMAS 
RCA  CORPORATION 
901  TRUPENNY  RD/PH  CHPT  DIR 
BLDG  206-1  RT  38  „„„ 

rucRBV  HILL  NJ  08358 


ALLAN  D  SIGNOR 
US  NAVAL  SEA  SYS  CMD 
CONFIG  DATA  MGR 
PO  BOX  296 

PORT  HUENEME  CA  93041 


OTAWAY  M. 
CUBIC  CORP 


THOMAS. 


Ill 


i  \  Y  1UL 

9333  BALBOA  AVE. 

SAN  DIEGO  CA 


MS  10-22 
92123 


RICHARD  P  SMITH 
HONEYWELL.  INC. 

MGR.  PRODUCT  DIFINITION 
13350  US  HWY.  19  S.  .  MS  740-4A 
CLEARWATER  FL  33516 


CHARLES  E.  TIEDEMANN 
MCDONNELL  DOUGLAS  ASTRO 
BLDG  101 /MEZ/MS410 
PO  BOX  516 

ST.  LOUIS  MO  63166 


D  L  SMOCK 

NAVAL  SPRT  WPNS  CNTR 
WHITE  OAK  LAB 
SUP  GEN  ENGR 

SILVER  SPRING  MD  20910 


ROBERT  I  TRAVIS 
MARTIN  MARIETTA  AEROSPACE 
CHIEF  ENGINEERING  SUP  SERV 
PO  BOX  179  M  #  0411 
DENVER  CO  80201 


R.  LEON  SNODGRASS 
E  G  G 
ENGINEER 

2150  FIELDS  ROAD 
ROCKVILLE  MD  20840 

THOMAS  F.  STACEY 
MASSEY-FERGUSON-PERK I NS 
ACTIVITY  COORDINATOR 
32500  VAN  BORN  RD. 

WAYNE  MI  48184 


PAULA  J.  STASIOWSKI 
NAVAL  AIR  SYST.  CMD. 

STAND.  SPEC.  ,  BLDG.  #2 
CODE  51122.  JEFFERSON  PLAZA 
WASHINGTON  DC  20361 

R  L  STEPHENSON 
HONEYWELL  INC 
SUPERVISOR-CONFIG  MGMT 
13350  US  HWY  19  S  MS  456-4A 
CLEARWATER  FL  33516 


MAURICE  E  TAYLOR 

ARMY  ARMAMENT  RStD  COMMAND 

ATTN:  DRDAR-TSTS 

DOVER  NJ  07801 


FRED  G  TESSIER 

INT'L  LASER  SYSTEMS 

CH— CONF I GUR AT I ON  MGMT /DATA  PRO 

3404  N  ORANGE  BLOSSOM  TRAIL 

ORLANDO  FL  32804 


WALTER  E.  THIELE 
GENERAL  MOTORS 
SUPV.  DRAFTING 
6767  HOLISTER  AVE. 
GOLETA  CA 


93117 


ALFRED  TURINO 
GTE  SYLVAN I A 

TECH  DATA  &  CONTROLS  MANAGER 
BOX  188 

MOUNTAIN  VIEW  CA  94042 


RONALD  L  VAN  BUSK IRK 
AEROJET  ELECTROSYSTEMS 
SUPV  DESIGN  SUPPORT  TAMS 
1100  W  HOLLYVALE  ST  BOX  296 
AZUSA  CA  91702 


JOY  L  VIARS 

DESIGNERS  5t  PLANNERS.  INC. 
SECTION  CHIEF  SUITE  700 
1725  JEFFERSON  DAVIS  HWY. 
ARLINGTON  VA  22202 

BARBARA  R.  VOGEL 
HONEYWELL.  INC. 

LEAD  WRITER/EDITOR  TECH.  PUB 
13350  U.  S.  HWY.  19  SOUTH 
CLEARWATER  FL  33546 


M  CATHLEENE  WADDELL 
NAVAL  SEA  SYSTEMS  COMMAND 
CONFIG  MGMT  ANALYST 
CODE  61Z4213.  NC2/7E48 
WASHINGTON  DC  20362 


M.  D.  WAL  CH 
HONEYWELL,  INC. 

DATA  MGMT.  ADMIN. 

2600  R IDGWAY  PARKWAY,  NE 
MINNEAPOLIS  MN  55413 


DR  PETER  C  C  WANG 
NAVAL  POSTGRADUATE  SCHOOL 
CODE  53  WG 


DEPTS  OF  MATH  8. 
MONTEREY  CA 


NATL  SEC  AFRS 
93940 


X-7 


feSISp?"§pi^LIST 

197  HANCE  AVE.  n7754 

T INTON  FALLS  NJ  07724 


EUGENE  W.  WRIGHT 

TECH  PUB.  CONSULTANTS 

MANAGER.  TECHDOC 

60  CHAPIN  ROAD  n-?n^n 

PINEBROOK  NJ  07058 


RICHARD  WELLS 
AFLC/CASO/LODSHC 
FEDERAL  CENTER 
BATTLE  CREEK  MI 


49016 


FRANK  K.  YOUNG 

ftSDS°15i3.  OFFICE 
1105  COLEMAN  AVE. 


95108 


RICHARD  WOZNICK 
CONSULTANT 
TECH  PUBLICATIONS 
1750  NEW  HIGHWAY 
FARMINGDALE  NY 


11735 


X-8 


l 


